Re: Multitouch review 2: press-and-hold

[Carlos Garnacho <carlosg gnome org>]

Hey,

On mar, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:
> API:
> 
> GtkWidget::press-and-hold
> GTK_PRESS_AND_HOLD_{QUERY,TRIGGER,CANCEL}
> GTK_STYLE_CLASS_PRESS_AND_HOLD style class
> GtkSettings::gtk-press-and-hold-timeout setting
> 
> This feature has a long history going back to 2005 and Hildon [1][2].
> 
> The way it works is that  ::press-and-hold is emitted upon button
> press (only button 1), scroll or touch events with an action of
> GTK_PRESS_AND_HOLD_QUERY. Widgets have to opt-in to press-and-hold by
> handling that and returning TRUE. GTK+ then plays the press-and-hold
> animation (which is adapted to whether you are using a tiny cursor or
> a fat thumb). If you hold still until the time determined by
> gtk-press-and-hold-timeout has passed, ::press-and-hold is emitted
> again with the TRIGGER action, and widgets are expected to handle that
> by doing whatever action they want to tie to long presses. If the
> press-and-hold is canceled because the pointer was moved (beyond the
> drag threshold), ::press-and-hold is emitted with the CANCEL action.
> If the widget goes away while the press-and-hold animation is running,
> it gets removed and cleaned up.
> 
> One interesting aspect here is that ::press-and-hold is emitted on the
> target widget of the event before the capture phase. There is a
> comment in the code that explains that this is 'so a parent capturing
> events doesn't delay nor prevent a child from doing the press-and-hold
> action'.

Exactly, this was most visible within scrolledwindows, you'd have to
wait for the scrolledwindow giving up on scrolling, plus the
is-this-really-a-long-click timeout, plus the actual press-and-hold
timeout, far too much waiting... So instead, press and hold is
triggered, and canceled later if necessary via _gtk_widget_grab_notify()

> 
> Questions, comments:
> 
> - This is almost convenience api - except for the interaction with
> event capture, every widget could do this itself with a timeout and a
> handrolled animation. But having this supported consistently across
> the desktop seems well worth it. The branch add press-and-hold support
> for the context menus in entries, labels and textviews.
> 
> - I wonder what happens on a multi-touch system - if I touch and hold
> 2 buttons, do I get two press-and-hold animations at the same time,
> with 2 context menus popping up in the end ?

Hm, right, I meant to have it work only for the touch sequence that
emulates pointer events, but forgot to do this change.

  Carlos