Multitouch review 2: press-and-hold


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

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 ?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]