Re: Multitouch review 6: gestures

[Carlos Garnacho <carlosg gnome org>]

On mié, 2012-02-01 at 13:38 -0500, Matthias Clasen wrote:
> API
>   GTK_GESTURE_SWIPE_{LEFT,RIGHT,UP,DOWN}
>   GTK_GESTURE_CIRCULAR_{CLOCKWISE,COUNTERCLOCKWISE}
>   gtk_widget_{enable,disable}_gesture
>   GtkWidget::gesture signal
>   GtkGesturesInterpreter
>   GtkGestureStroke
>   GtkGesture
> 
> There's a simple API here that consists of a number of predefined
> gestures - left/right/up/down swipes as well as circular motions.
> These can be enabled for a widget with gtk_widget_enable_gesture. GTK+
> then creates a gesture interpreter bhind the scenes, and feeds all
> touch events that are targeted to the widget to the interpreter. When
> an enabled gesture is recognized, the ::gesture signal is emitted.
> 
> It is possible to register new gestures by creating one or more
> GtkGestureStroke objects, combining them into a GtkGesture object, and
> then calling gtk_gesture_register_static. The resulting integer id can
> be passed to gtk_widget_enable_gesture to enable recognition of the
> custom gesture for a widget.
> 
> The GtkGestureInterpreter object is also available as public API, and
> it is possible to create one and do all the gesture recognition and
> event feeding manually - in that case, ::gesture is naturally not
> emitted.
> 
> Only touch events are looked at for gesture recognition.

Worth noting, by default. feeding the GtkGesturesInterpreter by hand
will work on events from any device.

> 
> Questions and comments:
> 
> - Is the GtkGestureInterpreter really something that we need to expose
> in public API ? It seems that that would only encourage bad ideas - or
> is there a concrete use case for this ?

I mainly was thinking about reusability here, we certainly may try to be
comprehensive wrt the stock gesture set, but we may still fall short
with specialized usecases.

> 
> - It seems to me that we feed touch events to the gesture interpreting
> machinery, but then proceed to handle them as normal - unlike the
> capture/release mechanism that we were talking about earlier. I guess
> a widget that is waiting for gestures is unlikely to have other uses
> for touch events.

That's indeed what happens. In complex scenarios, a gesture-aware widget
would want to discard touch events, or revert the effect of these
as ::gesture arrives. 

> 
> - The kinetic scrolling is looking for swipes - but is not using this
> gesture interpreter mechanism. Should it ?

I'd like to point out the difference between exact gestures and
"statistical" gestures. The former is better dealt with with the
GdkEvents itself, as coordinates/time could be needed to calculate
positions, accelerations and such. gdk_events_get_* may be handy in
the ::multitouch-event handler for those too.

The latter kind of gestures is unable to offer such detailed
information, but is more forgiving about the real gesture imperfections,
this is what GtkGesturesInterpreter does.

A middle ground could be having a gesture "hint" field in
GdkEventMultitouch. Being GtkGesturesInterpreter based on vector
comparison, it can fit the bill here, although such gesture hints
could end up not being that useful practically (eg. you can rotate and
zoom at the very same time, but you'd only get the hint for one of
those, so the interpreted state would lag behind the real state if you
solely rely on the hint).

  Carlos

> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list