gdk_touch_cluster_set_device() had to be called right after anyway,
so set the device directly within this call, and favor the most common
scenario where there's just 1 single multitouch device behind 1 master
device.
Now that GtkButton and GtkScale are multitouch approved, it's
sufficient to enable GDK_TOUCH_MASK on them to have them deal
with multitouch devices.
The scales set rgba of the currently selected rectangle, and
the button adds more rectangles, those can be manipulated
simultaneously together with the rectangles, the only limit
is the number of touches the touchscreen hw is able to detect.
GDK will only receive touch events when dealing with a multitouch
device, so these must be transformed to pointer events if the
client-side window receiving the event doesn't listen to touch
events, and the touch sequence the event is from does emulate
the pointer.
If a sequence emulates pointer events, it will result in a
button-press, N motions with GDK_BUTTON1_MASK set and a
button-release event, and it will deliver crossing events
as specified by the current device grab.
These are equivalent to an implicit grab (with !owner_events), so
if the touch leaves or enters the grab window, the other window
won't receive the corresponding counter-event.
Touch events don't generate crossing events themselves, so
do not rely on these to determine whether the button release
happened within the event window.
The implicit grab on priv->event_window already warrants that this
widget is the only one getting events while the button is pressed,
so don't spare the GTK+ grab here.
Likewise to pointer events, have touch events during a device
grab with owner_events=TRUE be delivered normally as long as
the widget pertains to the same window group.
If the touch sequence happens on a window with GDK_TOUCH_MASK set,
a GdkTouchGrabInfo is created to back it up. Else a device grab is
only created if the sequence emulates the pointer.
If both a device and a touch grab are present on a window, the later
of them both is obeyed, Any grab on the device happening after a
touch grab generates grab broken on all the windows an implicit
touch grab was going on, and all touches would be automatically
removed from every touch cluster.
If given an event coming from a touch devices,
this functions will read the MT major/minor/orientation
axes and return a cairo_region_t with the touch shape.
Although GtkGesturesInterpreter can be used standalone, GtkWidget
deserves helper API to enable support for gestures. gestures can
be enabled/disabled, and the ::gesture signal can be used to get
the gesture ID.
The internal GtkWidget gestures interpreter is only handled by
touch events, if gestures are needed for other devices, a
standalone gestures interpreter must be used.
The algorithm works on 2 GtkGestures, it finds out the similarity
of these by bending the user provided gesture so it equals a stock
one, the differences in areas are used to determine the level of
confidence on both gestures being similar.
This object is currently shallow, the API is defined but no gesture
interpretation is performed. Additional API is declared to create
and define gestures, which may consist of several strokes with an
offset.
These events are created from GDK_TOUCH_MOTION/PRESS/RELEASE
events, if the touch ID generating the event is within a
touch cluster, that event is stored and not pushed to the queue,
so a touch ID can only emit GDK_TOUCH_* or GDK_MULTITOUCH_* events
at the same time.
This event will gather all touches within a GdkTouchCluster,
including an array of the latest GDK_TOUCH_MOTION events for
the touch IDs contained in there.
In GtkWidget, touch events go through the same handler
than motion events, with the difference that touch_id
will have something meaningful there.
Touch events need to be explicitly selected, so if this
is enabled, the possibility of different motion streams
with different touch IDs must be handled in some way.
These are translated into GDK_TOUCH_PRESS/RELEASE GdkEvents,
which use the GdkEventButton struct, a touch_id parameter
has been added there to cope with touches.
These events' struct is the same than GdkEventMotion, which has been
added a touch_id parameter. The gdk_event_* functions have been modified
to also handle this event type.
This widget is too narrow to make touch interaction tricky enough, so
don't add the penalty of having the slider run farther from the touch
coordinates if it happens to miss the slider.
Instead of just stopping the acceleration source ID, check whether
it's overshooting, and let it snap back if needed after ::grab-notify
and ::button-release-event
Velocity calculation has been refactored out of the captured motion events
handler, and also has more tolerance defore determining that a drag is actually
still.
This is so submenus stay open as the parent menu item is pressed/released,
as the user would typically lift the finger in order to select a submenu
item.
