Jump to: navigation, search

Difference between revisions of "SWT/Multitouch support"

< SWT
m
Line 1: Line 1:
There is growing interest in supporting touch events and gestures in the SWT, and we want to consider adding it to the SWT for 3.7. The bugzilla bug requesting this feature is [https://bugs.eclipse.org/bugs/show_bug.cgi?id=279884 279884].&nbsp;
+
There is growing interest in supporting touch events and gestures in the SWT, and we want to consider adding it to the SWT for 3.7. The bugzilla bug requesting this feature is [https://bugs.eclipse.org/bugs/show_bug.cgi?id=279884 279884].&nbsp;  
  
This page will be used as a collecting point for platform API references, other work to draw from, and, eventually, API.
+
This page will be used as a collecting point for platform API references, other work to draw from, and, eventually, API.  
  
== References ==
+
== References ==
  
=== Platform support for touch and gestures<br> ===
+
=== Platform support for touch and gestures<br> ===
  
[http://msdn.microsoft.com/en-us/library/dd317323(v=VS.85).aspx MSDN guide to Windows Touch API]
+
[http://msdn.microsoft.com/en-us/library/dd317323(v=VS.85).aspx MSDN guide to Windows Touch API]  
  
 
[http://developer.android.com/guide/topics/ui/ui-events.html Android UI event handling]  
 
[http://developer.android.com/guide/topics/ui/ui-events.html Android UI event handling]  
Line 15: Line 15:
 
[http://blogs.gnome.org/carlosg/2010/06/09/getting-multitouch-to-just-work/ Blog] [http://www.j5live.com/2010/06/09/multitouch-working-in-fedora/ posts] on Gnome/GTK+ multi-touch (haven't seen links to API yet)  
 
[http://blogs.gnome.org/carlosg/2010/06/09/getting-multitouch-to-just-work/ Blog] [http://www.j5live.com/2010/06/09/multitouch-working-in-fedora/ posts] on Gnome/GTK+ multi-touch (haven't seen links to API yet)  
  
[http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-6ffb37601221e58cc29-8000.html Flash 10.1/AIR 2.0]&nbsp;support for touch events and gestures
+
[http://help.adobe.com/en_US/as3/dev/WSb2ba3b1aad8a27b0-6ffb37601221e58cc29-8000.html Flash 10.1/AIR 2.0]&nbsp;support for touch events and gestures  
  
 
=== Java touch event projects  ===
 
=== Java touch event projects  ===
Line 23: Line 23:
 
[https://sourceforge.net/apps/mediawiki/eclipsemultitch/index.php?title=Eclipse_Multi-Touch Eclipse plugin based on Kenai work]&nbsp;- EPL licensed  
 
[https://sourceforge.net/apps/mediawiki/eclipsemultitch/index.php?title=Eclipse_Multi-Touch Eclipse plugin based on Kenai work]&nbsp;- EPL licensed  
  
These are interesting because they will work on 10.5 and 10.6, but the implementation relies on a private framework. The only official AppKit support for touch events exists in 10.6.
+
These are interesting because they will work on 10.5 and 10.6, but the implementation relies on a private framework. The only official AppKit support for touch events exists in 10.6.  
  
 
== Requirements  ==
 
== Requirements  ==
Line 30: Line 30:
 
*TouchEvent, GestureEvent, ....  
 
*TouchEvent, GestureEvent, ....  
 
*TouchEventListener, GestureEventListener, ....  
 
*TouchEventListener, GestureEventListener, ....  
*A TouchEvent returns a collection of Touch objects that correspond to the set of touch points that made up the TouchEvent. A Touch represents one component of the TouchEvent. It has a phase that represents what the particular touch point is doing -- e.g., Touch_Start, Touch_End, Touch_Move, Touch_Resting, and an identifier that is unique for a given sequence of touches.
+
*A TouchEvent has a collection of TouchState objects that correspond to the set of touch points that made up the TouchEvent. A TouchState represents one component of the TouchEvent. TouchStates have:
*Generally speaking, a TouchEvent is fired when there is some change in state of the fingers on the touch pad.
+
**a phase that represents what the particular touch point is doing -- e.g., Touch_Start, Touch_End, Touch_Move, Touch_Resting  
*GestureEvents are higher-level constructs that represent an interpretation of TouchEvents. The SWT will make the necessary system calls to have the current TouchEvent interpreted for you, and will send GestureEvents as appropriate.
+
**an identifier that is unique for a given sequence of touches.  
*A GestureEvent will have additional gesture-specific information associated with it. For example, a RotateGesture will have a number of degrees that the user rotated their fingers, a ZoomGesture will have a scale factor associated with the pinch/stretch, a SwipeGesture will have a direction, and a TapGesture will have the number of taps. ''The names are strictly for discussion. The SWT pattern would lean towards subclasses of GestureEvent with named fields as opposed to a more general dictionary of properties. That seems to be the case for all of the platform APIs.
+
**a device ID that corresponds to the touchpad or trackpad that generated the event
*Mac and Windows have specific gesture callbacks for pinch/zoom and rotate. Mac has a Swipe gesture; Windows 7 does not. Windows 7 has a distinct gesture for two-finger tap or tap and hold; Mac does not.
+
**device height and width in pixels
*GestureEvent will return a collection of TouchEvents
+
**the location of the touch, represented as the fraction of the distance up or right from the edge of the device
*Control needs new methods to add and remove each kind of base listener class (likely TouchEvent and GestureEvent).  
+
**a flag indicating a 'resting' or ignored touch.
*Touches always go to the deepest Control in the visual hierarchy.  
+
*A TouchEvent is sent when there is some change in state of the fingers on the touch pad. The type of the event reflects what changed for that event.
*Clients only need to create a listener and add it to the Control - no additional coding necessary.
+
 
 +
<br>
 +
 
 +
*Control adds new methods to add and remove TouchListeners.  
 +
*GestureEvents are higher-level constructs that represent an interpretation of touch events.  
 +
*A GestureEvent will have additional gesture-specific information associated with it. For example, a RotateGesture will have a number of degrees that the user rotated their fingers, a ZoomGesture will have a scale factor associated with the pinch/stretch, a SwipeGesture will have a direction, and a TapGesture will have the number of taps. ''The names are strictly for discussion. The SWT pattern would lean towards subclasses of GestureEvent with named fields as opposed to a more general dictionary of properties. That seems to be the case for all of the platform APIs.''
 +
 
 +
*A Control can get TouchEvents ''or ''
 +
*GestureEvent has 3 notifications
 +
**GESTURE_BEGIN -- gesture is about to happen
 +
**GESTURE_PERFORM -- gesture is happening
 +
**GESTURE_END -- gesture finished
 +
*Mac and Windows have specific gesture callbacks for pinch/zoom, rotate, and panning/swiping. Windows 7 has a distinct gesture for two-finger tap or tap and hold; Mac does not.  
 +
*Touches always go to the deepest Control in the visual hierarchy.<br>

Revision as of 13:18, 23 June 2010

There is growing interest in supporting touch events and gestures in the SWT, and we want to consider adding it to the SWT for 3.7. The bugzilla bug requesting this feature is 279884

This page will be used as a collecting point for platform API references, other work to draw from, and, eventually, API.

References

Platform support for touch and gestures

MSDN guide to Windows Touch API

Android UI event handling

Mac OS X trackpad event handling

Blog posts on Gnome/GTK+ multi-touch (haven't seen links to API yet)

Flash 10.1/AIR 2.0 support for touch events and gestures

Java touch event projects

Project Kenai Mac multi-touch support - Apache licensed

Eclipse plugin based on Kenai work - EPL licensed

These are interesting because they will work on 10.5 and 10.6, but the implementation relies on a private framework. The only official AppKit support for touch events exists in 10.6.

Requirements

  • A collection of new Event subclasses and SWTEventListener subclasses will be defined
  • TouchEvent, GestureEvent, ....
  • TouchEventListener, GestureEventListener, ....
  • A TouchEvent has a collection of TouchState objects that correspond to the set of touch points that made up the TouchEvent. A TouchState represents one component of the TouchEvent. TouchStates have:
    • a phase that represents what the particular touch point is doing -- e.g., Touch_Start, Touch_End, Touch_Move, Touch_Resting
    • an identifier that is unique for a given sequence of touches.
    • a device ID that corresponds to the touchpad or trackpad that generated the event
    • device height and width in pixels
    • the location of the touch, represented as the fraction of the distance up or right from the edge of the device
    • a flag indicating a 'resting' or ignored touch.
  • A TouchEvent is sent when there is some change in state of the fingers on the touch pad. The type of the event reflects what changed for that event.


  • Control adds new methods to add and remove TouchListeners.
  • GestureEvents are higher-level constructs that represent an interpretation of touch events.
  • A GestureEvent will have additional gesture-specific information associated with it. For example, a RotateGesture will have a number of degrees that the user rotated their fingers, a ZoomGesture will have a scale factor associated with the pinch/stretch, a SwipeGesture will have a direction, and a TapGesture will have the number of taps. The names are strictly for discussion. The SWT pattern would lean towards subclasses of GestureEvent with named fields as opposed to a more general dictionary of properties. That seems to be the case for all of the platform APIs.
  • A Control can get TouchEvents or
  • GestureEvent has 3 notifications
    • GESTURE_BEGIN -- gesture is about to happen
    • GESTURE_PERFORM -- gesture is happening
    • GESTURE_END -- gesture finished
  • Mac and Windows have specific gesture callbacks for pinch/zoom, rotate, and panning/swiping. Windows 7 has a distinct gesture for two-finger tap or tap and hold; Mac does not.
  • Touches always go to the deepest Control in the visual hierarchy.