Re: Multitouch review 2: press-and-hold

[Simon Schampijer <simon schampijer de>]

Hi,

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:
> > > 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'.
> > >
> > > 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,
> > etc.).
>
> 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
> > animation?
>
> I think it gives good feedback that something is going to happen, and
> when.

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?

Regards,
   Simon