Re: Tap and Hold API

[Kristian Rietveld <kris imendio com>]

Hey Federico,

Sorry for the delay with getting back to you.

On Tue, Apr 17, 2007 at 02:17:12PM -0500, Federico Mena Quintero wrote:
> [snip]
> >   * Query: once the user presses the mouse button, this signal will be
> >     emitted to check whether the given location (x, y) allows for executing
> >     the tap-n-hold action.  The x and y parameters are set to the location
> >     of the mouse cursor (relative to the widget's allocation)  A return
> >     value of FALSE means no tap-n-hold action should occur.
> 
> As a widget, checking (x, y) based on your allocation is not convenient
> if you have subwindows.  Why not pass a complete GdkEventButton
> structure to the signal?  That way you can see the event->window and
> deduce things more easily.

I was actually planning to push in (x, y) relative to the widget->window.
The new tooltips code is supposed to do the same (however that
documentation says otherwise at this moment, it will be fixed RSN).  If we
use this, the window in question will also be known, since the coordinates
will always be relative to widget->window.  Most widgets handle this
already and usually have code/functions to translate from widget->window to
something else.  If they have not, this functionatily should be added to
those widgets IMHO.

Passing a GdkEventButton instead does not really seem beneficiary to me; we
cannot use the original GdkEventButton we get from the button-press since
the event time and coordinates will likely be wrong, so we will end up with
a synthesized event anyway.  Another point: for tooltips we don't pass in
motion events or something similair either ...

> [If you have a simple stylus I guess you don't need to know about a
> particular mouse button.  Are there styluses for which you would need a
> button number?  Tap-and-hold-while-pressing-a-certain-button-
> in-the-fancy-wacom-stylus?]

My wacom tablet does seem to have two different kind of the buttons, since
I can use the back of the "stylus" (which is really more like a pen) as an
eraser.  I can press a button on the side to get it do even something else.
I am not really sure if having different tap-n-hold actions for different
mouse buttons is worth supporting.  I think I would prefer tap-n-hold to
run the same action for any button, since it's about tapping and holding
something on the screen, whether this is a stylus, a finger or the back of
wacom pen is left in the middle.

> >   * Trigger: if the application returned TRUE in response to the query
> >     signal and the user hold the button and did not move the mouse past the
> >     threshold (currently the drag threshold is used for this) during the
> >     timeout period, this signal will be emitted.  X and y again reflect the
> >     position of the mouse cursor.  The return value of the signal is not of
> >     any significance and ignored.
> 
> What happens when you already have a button-press-event handler?  Or is
> the intention that you replace that handler with the tap-and-hold one?
> 
> [I.e. is it easy to retrofit apps to support tap-and-hold with ths new
> API, or do all the event handlers need to be changed?]

The plan is to emit the tap-n-hold signal only if the original button-press
signal remained unhandled.

> > A GtkSetting called "gtk-tap-and-hold-timeout" has been added, which is
> > used to set the tap-n-hold timeout.
> 
> Does this interact the Right Way with respect to widgets that already
> have automatic drag handlers set up for them?  I.e. you tap and hold for
> a bit, then actually drag.  The widget should emit tap-and-hold(cancel)
> and then drag-begin.

I did some quick testing with a GtkTreeView with both tap-n-hold and the
drag source enabled, and it already behaves as you specified.

> > During the timeout period between pressing the button and triggering the
> > tap-n-hold action the mouse cursor will be replaced by an animation,
> > indicating that "something" is happening.
> 
> I guess this has to be experienced to get a good feel, but my
> spider-sense tells me that widgets will prefer to show the "I'm armed"
> state by themselves, rather than relying on an automatic cursor.  How
> would the widget change the cursor itself when it gets the "trigger"
> version of the signal?  Do we need an API analogous to
> gtk_drag_set_icon_*()?

I don't think having widget-specific tap-n-hold animations is a good idea;
I would say that this is really a theme issue and it would be good if
every tap-n-hold operation "looks the same" the to user.  This issue is
different for drag-n-drop, there you have a standard cursor and the
gtk_drag_set_icon_*() API makes it possible for the user to set an icon
next to that standard cursor giving some more context about what they are
dragging.

> > Another questionable point is whether we should allow for tap-n-hold
> > actions to be triggered via the keyboard.  This is probably a good thing
> > to do and would involve adding a gboolean "triggered_by_keyboard" to the
> > signal signature, just like the new tooltips API has.  Does anyone have
> > better suggestions here?
> 
> But then you would need to bind a key to the tap-and-hold action, and
> that gets messy.

I think that depends on the way you want to implement it.  For tooltips you
can activate the show-help binding which will display the tooltip for the
focussed widget immediately, without any delay.  For tap-n-hold I was
thinking of something similiar, a keyboard shortcut which will activate a
binding -- this binding will trigger the tap-n-hold action immediately (iff
the query succeeded of course).



thanks,

-kris.