Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "SWT/Multitouch support"
< SWT
| Line 30: | Line 30: | ||
*TouchEvent, GestureEvent, .... | *TouchEvent, GestureEvent, .... | ||
*TouchEventListener, GestureEventListener, .... | *TouchEventListener, GestureEventListener, .... | ||
| − | *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. | + | *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. |
| + | *Generally speaking, a TouchEvent is fired when there is some change in state of the fingers on the touch pad. | ||
| + | *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. | ||
| + | *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. | ||
| + | *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. | ||
| + | *GestureEvent will return a collection of TouchEvents | ||
*Control needs new methods to add and remove each kind of base listener class (likely TouchEvent and GestureEvent). | *Control needs new methods to add and remove each kind of base listener class (likely TouchEvent and GestureEvent). | ||
*Touches always go to the deepest Control in the visual hierarchy. | *Touches always go to the deepest Control in the visual hierarchy. | ||
*Clients only need to create a listener and add it to the Control - no additional coding necessary. | *Clients only need to create a listener and add it to the Control - no additional coding necessary. | ||
Revision as of 20:14, 17 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.
Contents
References
Platform support for touch and gestures
MSDN article on WM_TOUCH events
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. 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 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.
- Generally speaking, a TouchEvent is fired when there is some change in state of the fingers on the touch pad.
- 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.
- 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.
- 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.
- GestureEvent will return a collection of TouchEvents
- Control needs new methods to add and remove each kind of base listener class (likely TouchEvent and GestureEvent).
- Touches always go to the deepest Control in the visual hierarchy.
- Clients only need to create a listener and add it to the Control - no additional coding necessary.