Re: Keynav implementation issues

[Owen Taylor <otaylor redhat com>]

OK, here are my currently planned resolutions for all these issues.

> Bindings on parent widgets:
> 
>  The keynav design calls for various bindings on widgets that should
>  take effect if focus is on any child widgets. This include:
> 
>   Ctrl-PgUp/PgDown to switch pages in a notebook
>   Ctrl-Tab to focus out of notebook
>   F8 to focus through GtkPaned splitter bars "currently in context"
>   F6 to to focus among panes "currently in context"
> 
>  The Swing key binding system has a concept where key bindings can:
> 
>    - Apply only when the widget has focus
>    - Apply when the widget or any child has focus
>    - Apply when any widget in the same toplevel has focus
> 
>  While something like this could be implemented in GTK+, it probably
>  is overkill. There are various possibilities:
> 
>    - Hack all such keybindings into GtkWindow.
>    - When focus is moved inside such a widget, set up a temporary
>      signal connection on the toplevel and handle keystrokes there.
>    - Make GTK+ propagate keystrokes not just to the focus widget
>      then to the toplevel but through all intermediate widgets
>      as well.
> 
>   I suspect the last one is the best solution, though there is some
>   risk of unintended side effects if you have nested widgets taking
>   key input.

I think eventually, we'll have to move to something better. I think
that is simply:

 void  gtk_binding_entry_add_signal_extended (GtkBindingSet	*binding_set,
                                              GtkBindingContext  context,
				              guint		 keyval,
				              guint		 modifiers,
				              const gchar	*signal_name,
				              guint		 n_args,
				              ...);

But there are other missing pieces to implementing this properly, a few
being:

 * An RC file syntax.

 * A global keystrokes table on the toplevel that holds:
   - Accelerators
   - mnemonics
   - Bindings 
   - Input contexts (this is a little tricky since input context may want
     "all unmodified keystrokes")

 * The idea of installing and uninstalling keystrokes from this table
   when widgets are added and removed from toplevels, focus changes, 
   etc.

I think we can manage to do this stuff compatibly in 2.2; I think 
squeezing it in at this point for 2.0 would be a mistake.

So, for now, I'm just going to add "keystrokes propagate to parent
widgets, which fits in well with our current model of "pass key
strokes around until someone handles it".
 
> Remembering the "last focus" within a child widget.

Can be done currently, as Soeren points out.
 
> Keynav for toolbars:

I'd like to just not do this for 2.0 if possible. (See my other mail.)
 
> Mnemonics activation without alt:

Can just put this in gtk_window_key_press(), as Padraig points
out. Need some sort of gtk_window_mnemonic_activate_ignoring_modifiers(), 
but that can be private.

> Popping down tooltips
> 
>  (I'm not sure if there was a final decision on what the desired
>  behavior was. In some experimentation, it seemed to me that
>  what might be nice would be if Ctrl-F1 put the window into
>  a "keyboard tooltips mode" where the tooltip was always displayed
>  for the currently focused widget and never for the mouse,
>  and Escape would cancel that mode. Perhaps focusing out of the
>  toplevel would deactivate the mode as well.)
> 
>  When a tooltip is popped up via the Ctrl-F1 binding, Escape should
>  pop it back down. This poses a problem because Escape has a different
>  function that should take unless tooltips are popped up.
> 
>  If you are willing to hard-code Escape, there are multiple ways
>  of doing this - just hardcoding it into gtk_window_key_press() 
>  would be the simplest. A little more general than hardcoding
>  would be to do it like F10 is currently handled - as a string
>  setting that is converted into a key stroke.
> 
>  A more general approach would be to add an idea of an "optional
>  keybinding" - if the action signals connected to a key
>  binding have boolean return values and they all return FALSE,
>  then the key press is considered not handled.

The optional keybinding isn't enough - we'd also have to some how
have an optional keybinding with a priority greater than the 
mnemonics / accelerators / keys sent to the widget.

So, I think a quick a hack here is the right approach. It doesn't
particularly matter which one ... I think for consistency we
should probably do it a bit like GtkMenuBar:

 - Put the key binding as a string into a GtkSetting
 - Add a signal connect to GtkKeyPress on the toplevel when
   going into "browse tooltips" mode.
 - Remove the signal connection when leaving the mode.

The first one of these is optional, and we could just hardcode
"Escape", but it would be a slightly nicer touch.

Regards,
                                        Owen