Overhaul Mandoline event transport code

ui/mojo/events/input_events.mojom

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 module mojo;
 
 import "ui/mojo/events/input_event_constants.mojom";
 import "ui/mojo/events/input_key_codes.mojom";
 import "ui/mojo/geometry/geometry.mojom";
 
@@ skipping 29 matching lines @@
 
   // The text generated by this keystroke. Corresponds to
   // blink::WebKeyboardEvent::text.
   uint16 text;
 
   // Like |text|, but unmodified by concurrently held modifier keys (except
   // shift). Corresponds to blink::WebKeyboardEvent::unmodifiedText.
   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 {
   // TODO(sky): rename to type.
   EventType action;
   // TODO(sky): parts of this should move to PointerData.
   EventFlags flags;
   // Time in microseconds from when the platform was started.
   // This value accurately orders events w.r.t. to each other but
   // does not position them at an absolute time.
   int64 time_stamp;
   KeyData? key_data;
   PointerData? pointer_data;
 };