Overhaul Mandoline event transport code

ui/mojo/events/input_events.mojom

Index: ui/mojo/events/input_events.mojom
diff --git a/ui/mojo/events/input_events.mojom b/ui/mojo/events/input_events.mojom
index 3824d5621aeebd6785ce2203433d9be567e3ae39..9c58743716ffe3aae58cf373085496c1ea5e49a5 100644
--- a/ui/mojo/events/input_events.mojom
+++ b/ui/mojo/events/input_events.mojom
@@ -47,22 +47,56 @@ struct KeyData {
   uint16 unmodified_text;
 };
 
+// TODO(rjkroege,sadrul): Add gesture representation.
 struct PointerData {
   int32 pointer_id;
   PointerKind kind;
   // |x| and |y| are in the coordinate system of the View.
+  // Typically, this will be an integer-valued translation w.r.t.
+  // the screen and in this case, |x| and |y| are in units of physical
+  // pixels. However, some View embedders may apply arbitrary transformations
+  // of a view w.r.t. the screen.
   float x;
   float y;
-  // |screen_x| and |screen_y| are in screen coordinates.
+  // |screen_x| and |screen_y| are in screen coordinates in units of
+  // physical pixels.
   float screen_x;
   float screen_y;
+  // Some devices (e.g. trackpads or mice) have additional valuators
+  // such as the mouse wheel or ball. Present only if kind is WHEEL.
+  WheelData? wheel_data;
+  // Some devices (e.g. pen, finger) can extend across multiple pixels
+  // at once. |brush_data| provides additional data for this case and
+  // is available when |kind| is PEN or TOUCH.
+  BrushData? brush_data;
+};
+
+// Information payload to support
+// https://developer.mozilla.org/en-US/docs/Web/Events/wheel.
+// TODO(rjkroege): Handle MacOS momentum scrolling.
+struct WheelData {

[sadrul, 2015/09/09 04:19:05]

Would it make sense to make this ScrollData? (e.g. we could possibly reuse this
for scrolls from gestures/touchpads?)

[rjkroege, 2015/09/09 19:45:38]

I have this long frustration with the re-use of wheel events to mean scrolling.
I think we should separate scrolling from wheel events because (by spec) Wheel
events are delivered sync to JS and can be PreventDefault()-ed while scrolling
generates (async) scroll notify events that cannot. As a result, I claim that
code will end up more understandable if we keep these two concepts separate.
WDYT?

[sadrul, 2015/09/10 17:39:15]

Re-using wheel events to mean scrolling does sound bad. Although in this case, I
am suggesting having a more explicit Scroll* struct that the various kinds of
events could use. So a WHEEL event can include some Scroll* struct if it is
meant to trigger scrolling, while a gesture-scroll event can also include the
same Scroll* struct, thus we avoid introducing similar struct for essentially
the same purpose. Does that make sense?

[rjkroege, 2015/09/12 01:29:02]

At some level yes. But we don't know if a wheel is meant to trigger scrolling.
If we knew, MUS would have scrolled and not need to send the event at all. A
wheel event is sent to the app iff it might not mean scrolling.

I want to deal with gesture event payloads in a future CL.

+  WheelMode mode;

[sadrul, 2015/09/09 04:19:05]

As per above, ScrollMode?

[rjkroege, 2015/09/09 19:45:38]

see the above. I will update this after updating the name of WheelData as
appropriate

+  // |delta_x|, |delta_y|, |delta_z| can be in units of pixels, lines, pages
+  // or control scaling as controlled by |mode|. Pixel scroll is physical
+  // pixels in the coordinate system of the target View.
+  float delta_x;
+  float delta_y;
+  float delta_z;
+};
+
+// Supplementary data to support pointers where the pointer can
+// cover multiple pixels per http://www.w3.org/TR/pointerevents/
+struct BrushData {

[sadrul, 2015/09/09 04:19:05]

'Brush' here seems awkward, but I don't have a suggestion for a better name (I
was going to suggest PointerDetails, as we do for ui::Event, but that could be
confusing with PointerData here).

[rjkroege, 2015/09/09 19:45:38]

Brush: short, analogous with paint programs. Am happy to use a different word
but Pointer is dangerously close to being as over-used as View. :-)

[sadrul, 2015/09/10 17:39:15]

Heh, yeah. I am OK with Brush until we can think of a better name 

+  // |width| and |height| are in CSS pixels in the coordinate system of
+  // the target View.
+  float width;
+  float height;
+  // |pressure| range is [0,1]. It will be set to 0.5 when the device cannot

[sadrul, 2015/09/09 04:19:04]

The 'unknown' value for pressure in the spec is 0, and 0.5 only when there is an
active point (i.e. button/touch-point down). Clarify the comment here
accordingly?

[rjkroege, 2015/09/09 19:45:38]

Done

+  // provide the actual value.
   float pressure;
-  float radius_major;
-  float radius_minor;
-  float orientation;
-  // Used for devices that support wheels. Ranges from -1 to 1.
-  float horizontal_wheel;
-  float vertical_wheel;
+  // |tiltY| and |tiltX| are in degrees.
+  float tiltY;
+  float tiltZ;
 };
 
 struct Event {