Re: Tooltips keynav patch

[Owen Taylor <otaylor redhat com>]

"Padraig O'Briain" <Padraig Obriain Sun COM> writes:

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

It's not technically difficult... it's just like propagating whether the toplevel
is focused/activated down through the hierarchy which is done currently.

(Doing it this way, we'd probably want to make Control-F1 an accelerator on the
toplevel rather than on particular widgets so we wouldn't have to push the
information both ways through the protoco.

The only problem is that the plug/socket protocol is supposed to be standardized,
and while it's still somewhat experimental, I don't want to add lots of GTK+-specific
hacks to it. 

One possibility would be to look at adding some sort of extensible
"toplevel property list" where you could annotate the toplevel with a
bunch of atoms and that information would be propagated down.
 
But for GTK+-2.0 it might be best to simply leave things a little broken rather
than going for a lot of complexity.

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

I think it would be confusing if Control-F1 only toggled the "keyboard-focus-mode"
if the widget had a tooltip.

Regards,
                                        Owen