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