Re: Keynav implementation issues
- From: Owen Taylor <otaylor redhat com>
- To: gtk-devel-list gnome org
- Cc: padraig obriain sun com
- Subject: Re: Keynav implementation issues
- Date: 24 Oct 2001 16:46:25 -0400
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,
const gchar *signal_name,
But there are other missing pieces to implementing this properly, a few
* An RC file syntax.
* A global keystrokes table on the toplevel that holds:
- 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,
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.
] [Thread Prev