A GList doesn't make much sense for storing guints, so
now a GArray is used internally.
gdk_touch_cluster_get_touches() has changed to return an
allocated guint*, and gdk_touch_cluster_get_n_touches()
has been added too.
Use a separate boolean instead of coding it up in the last button press
coordinates. This incidentally fixes 0-threshold on kinetic scrolling,
allowing the child widget to get button releases before it prematurely
gets ::grab-broken.
Gestures are only compared with stock gestures with the same number
of strokes. If a gesture consists of several strokes, the first stroke
is compared (and any possible angle skew is gotten from it), and then
the other strokes are correlated and also compared.
If there's no feasible correlation of strokes, or the gestures yield
an accumulated confidence that's below the threshold, the gesture is
not considered to match.
testgestures has been also added a simple 2-finger gesture for testing.
The widget window is usually covered by the bin_window,
this is just necessary so the parent scrolled window
picks the right color for drawing the overshoot area.
The widget window is usually covered by the bin_window,
this is just necessary so the parent scrolled window
picks the right color for drawing the overshoot area.
The widget window is usually covered by the bin_window,
this is just necessary so the parent scrolled window
picks the right color for drawing the overshoot area.
This call gets the number of currently active strokes, finished
strokes (i.e. those that already had a GDK_BUTTON/TOUCH_RELEASE
processed) don't count.
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.
