Re: Tap and Hold API

[Federico Mena Quintero <federico ximian com>]

On Thu, 2007-04-26 at 23:40 +0200, Kristian Rietveld wrote:

> 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.

Hmm, if you make it relative to widget->window, I suppose it's okay.
It's cumbersome when you have more than one subwindow, though (we have
had this inconvenience since the DnD API was introduced).

> 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 ...

The point is that you *do* need a timestamp that makes sense :)  Let's
say you tap-and-hold; the program will likely want to pop up a
tooltip-like window (or popup menu or similar) and those require a
timestamp.  It could simply be the timestamp from the initial "tap", or
from the latest motion event that is still considered part of the
"arming" period.

> 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.

Pen computers will likely not care since the stylus has no buttons, but
for a Wacom tablet I can very well imagine a tap-and-hold action that is
different for the brush than for the eraser.  Maybe such sophisticated
apps will be content implementing tap-and-hold by hand anyway :)

> 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.

You have two tap-and-hold actions: pop up a menu and pop up a tooltip
with extra info.  Should those have the same "I'm armed" animations?

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

Oh, so this would be global?  Sort of

  tap-and-hold-keysym = "FunkyKey"

in your ~/.gtkrc?

  Federico