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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list