Re: Tooltips keynav patch

["Padraig O'Briain" <Padraig Obriain Sun COM>]

I have had a look at what Calum has specified in 
http://developer.gnome.org/projects/gap/keynav/gtk_tooltips.html

We now have a way to post the tooltip for a focused widget and unpost it using 
the keyboard. When focus is moved from widget to widget, the tooltip changes to 
that of the focused widget. We do not use the Esc key to unpost but that is not 
important to me. Perhaps, Calum has a different view.

I would love to see this patch applied. 

The plug-socket issue described below means that the keyboard-tooltips-mode is 
lost if focus moves through the plug-socket in either direction. How feasible is 
it to push this information through the plug-socket?

As regards propagating to parent widgets, should 
_gtk_tooltips_toggle_keyboard_mode() return FALSE if the widget does not have a 
tooltip?

Padraig


> To: gtk-devel-list gnome org
> Cc: padraig obriain sun com
> Subject: Tooltips keynav patch
> User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/21.1
> MIME-Version: 1.0
> 
> 
> I was looking at the Bug 53614, "KEYNAV: GtkTooltip" and the patch
> from Padraig on there. The patch seemed to implement the right
> behavior, but I wasn't entirely comfortable with the way it did
> things, in particular the changes to gtkwindow.c.
> 
> So, I took a stab at reimplementing it, attached below; this version
> is mostly inside gtktooltips.c with a small change in gtkwidget.c
> 
> Limitations of this patch:
> 
>  1) It doesn't fully work with plug-socket. That is, every GtkPlug
>     has a separate "keyboard mode" setting that Control-F1 in a widget
>     in that plug toggles.
> 
>  2) It doesn't implement the suggested Escape to get out of keyborad mode
>     you have to press Control-F1 again. 
> 
>     Implementing the Escape key binding is rather a nuisance - it can't
>     be done with a keybinding, since it must have a _higher_ priority
>     than the Escape accelerator to close a dialog. The way it would
>     need to be done is to define the keybinding with a GtkSetting
>     (as in Padraig's patch), then make a signal connection to key-press-event
>     when turning on keyboard-mode for a toplevel. (But that wouldn't 
>     work at all for plug-socket.)
> 
>  3) It breaks the newly introduced propagating-Control-F1 behavior,
>     since Control-F1 always simply toggles the keyboard mode.
> 
>     If we want to support tooltips for parent widgets, it probably 
>     should be done by making "keyboard mode" search for a parent widget
>     with a tooltip if the focus widget doesn't have one, and show
>     that. This shouldn't be that hard to implement.
> 
> It's certainly far from perfect, but I think is a lot more useable than
> what is in CVS, and we'll probably have to live with something at
> about this level of functionality for GTK+-2.0.
> 
> Regards,
>                                         Owen
>