Re: Multitouch review 2: press-and-hold


first of all, thanks for all the work on this!

I just tested the multitouch branch here on my Wetab in a little python example to get a feeling what the API would be like. The approach to connect to a signal and then decide whether to handle it or not was straight forward to me.

On 02/01/2012 05:23 PM, Carlos Garcia Campos wrote:
Excerpts from Bastien Nocera's message of mié feb 01 12:23:52 +0100 2012:
On Tue, 2012-01-31 at 19:18 -0500, Matthias Clasen wrote:

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:
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,

IIRC, animation will only work if GtkSettings:gtk-enable-animations is TRUE.

Yes, from my testing here, the animation is not shown when setting the property to FALSE.

Can we please get the code writers' reasoning behind having this

I think it gives good feedback that something is going to happen, and

I think it is good feedback, indeed. I wonder if the diameter could even be a bit larger (or configurable). If you compare mouse or finger presses, for finger presses the animation is a bit covered under the finger.

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)?

Yes I think I added a style class for press and hold animation, so
it's themable.

There is a style class:

.press-and-hold {

background-color: alpha (@bg_color, 0.5);

color: alpha (lighter (@selected_bg_color), 0.8);

  border-width: 10;

If my testing was correct, setting the background color does set the background color of the widget as well. Is this desired? What does the 'border-width' is meant to do in this particular case? As far as I understood, the animation sizes are proportional to the input pointer (e.g. finger or mouse pointer) does this border size has any effect?


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