Provide API for motion events

[jkrause]

No description provided.

[mpost]

After discussion with the client team, we will provide support for MouseDown, MouseUp and MouseMove events which should be backed up by matching tabris-js nomenclature.

[tbuschto]

The existing mouse events are unsuitable to base touch events on. They don't bubble, don't enable multi-touche/gesture events and don't offer "cancel" or "tap" events to recognize if an element was released outside it's bounds.

Here is a draft for "real" touch events in tabris-js, inspired mostly by HTML5 (http://www.w3.org/TR/touch-events/). Note that there is also a effort by MS to get their own pointer/gesture events to be standarized (http://www.w3.org/TR/pointerevents/, http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh441180.aspx#properties).

  {
    type: "touchstart" | "touchmove" | "touchend" | "touchcancel", // "touchcancel" = touchend outside widget
    time: number, // like all events have
    cancelBubble : fn, // unlike SWT mouse event, these do bubble
    touches : [ { x: number, y: number, id: string }, ... ], // only those that started on the target, in order of age (oldset first)
    target: widget, // the target is always the widget where the touches started
  }      

A minimal implementation would only require the "touches" array, the other fields are noted here mostly for behavior documentation. There could also be an "changedTouches" array.

In addition to these "low-level" events there could be event for simple one-touch-single-event gestures fired after a touch session, like "tap", "longpress" and possibly double-top and/or fling. (MS calls it "InertiaStart"). These may require some intelligence since only of of them should be fired per touch session, even if there are multiple available targets. Multi-touch gesture will very likely require a more complex API than simple listener.

[tbuschto]

As an intermediate solution we will transform the mouse events into touch events in the JavaScript code. This means that there will be potentially breaking changes (in behavior, not necessarily API) when we then implement propper touch events. The native client will have to fix the behavior of mouse events in case of multiple touches though.

[mpost]

@tbuschto The android client filters touch events beyond the first finger already. Meaning you will not receive Mouse events for a second finger while one is already down.

Not though... That we do send a second MouseDown for finger 1 after the "long press duration" with button = 3 (other mouse events use button = 1.

[tbuschto]

Commit adc067e renamed the events as suggested and introduces the "touches" array. I will close this issue for now (since this is all we will do fo for this feature in M2). I will open another issue for multi-touch/gesture support.