Re: Multitouch review 2: press-and-hold

On Tue, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:
> API:
> GtkWidget::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
> action'.
> Questions, comments:

I still think that the press and hold animation has no place here. Apart
from Windows, I've not seen any touch or stylus devices use this, and I
seriously doubt its usefulness (versus it looking tacky, out of place,

Can we please get the code writers' reasoning behind having this
animation? What do the designers think? Should it be something the theme
chooses to implement (so that the Windows theme would use the Windows
animation for that for example)?


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