Re: Keynav implementation issues

[Owen Taylor <otaylor redhat com>]

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

> > Keynav for toolbars:
> > 
> >  The keynav spec specifies that F10 switches between all menus and
> >  toolbars in the current window. Keynav in menus in GTK+ is not
> >  currently handled through the focus system. However, toolbars can
> >  contain normal widgets entries in them and probably need to go
> >  through the normal focus system.
> > 
> 
> Actually between menubar and toolbars. There is at most one menubar which is 
> specified as a property of the GtkWindow. As far as I can see there can be more 
> than one toolbar but I do not see a way of identifying them.

The limitation to one menubar in a toplevel is nothing fundemental -
it's just something in the F10-activation in GtkMenuBar and if we
had a way to switch between different menubars and toolbars (say,
F10 followed by Tab) then could easily be removed.
 
In terms of locating toolbars, I would imagine that what you would
do is add some API to GtkWindow:

 gtk_window_register_aux_keynav_widget ();
 gtk_window_unregister_aux_keynav_widget ();

And GtkToolbar and GtkMenubar would register themselves when
added to a topplevel and unregister themselves when removed.

Then there would be a:

 gtk_window_aux_keynav_widget_focus ();

That gtk_menu_bar_focus() gtk_toolbar_focus() could call in
response to TAB_NEXT/TAB_PREV.

> >  (This does raise the issue that if you things like a location entry
> >  in a toolbar, the location entry possibly should be part of the main
> >  focus chain.)
> 
> There does not seem to be any visual feedback or notification of when the mouse 
> is over a entry in a toolbar. I think there should be.

I don't quite understand - there is no feedback when a mouse
is over a normal entry.

[...]

> >  A different approach would be to handle key navigation in a GtkMenu
> >  with menus popped down through the normal focus system. (But not put
> >  menu bars and toolbars in the normal focus chain.) So, F10 would
> >  focus the menu bar, toolbar, etc, but not establish a grab. The grab
> >  would only be established when the first menu was popped up.
> > 
> 
> Would F10 for menus popup the menu of the first menu item in the menubar?

I would think not. Once menus are popped up, you need to have a grab,
and if we are handling F10 contexts as "normal" key focusing, its
probably best not to have a grab involved.
 
> Currently the normal focus chain uses GTK_WIDGET_CAN_FOCUS to determine what 
> widgets are in the focus chain. It sound like some additional mechanism is 
> needed for widgets such as menubars and toolbars which should not be in the 
> normal focus chain but whose children should be able to receive focus.

Actually, GTK_WIDGET_CAN_FOCUS() is only used in the default
implementation of the ::focus signal. Widgets can override 
::focus and decide in a more dynamic way whether they accept
focus or not.

(There was a "prefiltering" step in gtkcontainer.c's focusing
handling, but that was only an optimization, and my last patch
removed it.)

It's perfectly possible for a widget such as a menubar or toolbar
to deny focusing into it via the keyboard but to allow focusing
within it.

> >  (There would then need to be some mechanism for saving the focus
> >  within the main window since the focus was actually being moved;
> >  this is related to the above issue.)
> > 
> > Mnemonics activation without alt:
> > 
> >  The proposal suggests that if the current control doesn't accept
> >  keyboard input, then mnemonics should be accessible without
> >  the Alt key.
> > 
> >  One way that it might be possible to do this is to handle 
> >  unmodified mnemonics in gtk_widget_real_key_press_event(); if
> >  a keystroke was not otherwise intercepted, then it would
> >  be interpreted as a menomic. Problems with this are:
> > 
> >   - There is no requirement currently for widgets to chain
> >     up their key_press handlers - they can simply call
> >     gtk_bindings_activate() themselves.
> > 
> >   - If a widget handled only some unmodified keystrokes and
> >     not others, the result could be quite confusing.
> > 
> >  A different technique would be to have some sort of widget
> >  flag "handles_custom_key_input" and do processing of 
> >  unmodified mnemonics only if the focus widget didn't have
> >  that flag set. I don't particularly like this idea though -
> >  people are likely to forget to set/clear this flag; plus
> >  it just doesn't seem to be the "GTK+ way".
> > 
> >  A simpler fallback (also suggested) would be to  make whether 
> >  unmodified mnemonics are allowed as a GtkWindow property,
> >  which could be defaulted to the correct value for 
> >  GtkMessageBox.
> > 
> 
> Do I understand correctly that all processing of keyboard input goes through 
> gtk_window_key_press_event()? Would it be possible to attempt to handle a 
> mnemonic without alt at the end of this function if the event remains unhandled?

Yes, this would work and is better than most of my suggestions above :-)

                                        Owen