Re: Tap and Hold API

[Tim Janik <timj imendio com>]

On Tue, 1 May 2007, Federico Mena Quintero wrote:

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

more than one subwindow is always cumbersome, if we delivered subwindow 
relative coordinates, we'd still have the problem of finding the exact
subwindow in the widget code (and depending on the widget implementation,
it may or may not already have code to translate back to widget->window).
delivering widget->window really is the easiest choice because every widget
implementation already knows how to translate from widget->window -> subwindow
(after all that's needed to correctly position subwindows in the first place)
and generic code that has no intrinsic knowledge of a widget's window layout
can still make use of the coordinates.

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

ah, an interesting point, worth considering...
the case where "activate_time" stamps are actually required are popup menus:

/**
 * gtk_menu_popup:
 * @activate_time: the time at which the activation event occurred.
 *
 * The @activate_time parameter should be the time stamp of the event that
 * initiated the popup. If such an event is not available, use
 * gtk_get_current_event_time() instead.
 *
 */
void
gtk_menu_popup (GtkMenu             *menu, [...]
                guint32              activate_time);

the activate_time parameter is actually used to initiate the mouse/keyboard
grabs. X needs that to conflict-resolve grab requests with concurring grab
requests by other apps. so tooltip-like windows that don't need to acquire
a grab are not affected here.
tap-and-hold is often used to popup menus though, which need an activate_time
parameter. now the problem is, what time should be passed in here in the case
of a tap-and-hold period expiring? usually, the time of the causally related
event is used, but in the tap-and-hold case, that time is always too late
(since tap-and-hold behavior always needs a hold period >0 to make sense).
so we'd actually need something like button_press->activate_time + hold_period
(just using button_press->activate_time or last_motion->activate_time directly
and assuming hold_period=0 wouldn't be a time stamp suitable for conflict
resolution).
given that an apropriate hold_period calculation would be fairly complex,
and that at the point of the hold_period expiration any timing jitter from
the original button-press delivery probably has become quite irrelevant,
"button_press->activate_time + hold_period" would just be a rather bad
approximation of "now". and "now" is something that we are actually able
to specify precisely by using GDK_CURRENT_TIME.

so i'd say that tap-and-hold expiration is one of the rarer cases, where
one should always use GDK_CURRENT_TIME for menu popups. that in turn means
there's no point in carrying across a time stamp (which would be outdated
or misleading anyway) in the tap-and-hold API. it might make sense to add
this consideration to the docs though.

>  Federico

---
ciaoTJ