Re: Keynav implementation issues

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

[SNIP]

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

>  (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.

> 
>  Padraig's current patch in #54047 takes the approach of making key
>  navigation in toolbars work like that menus - with a grab and
>  handling keystrokes more or less directly without having the focus.
> 

I would not regard my patch as anything other than a learning exercise. I found 
that there was a difference between manipulating the toolbar using the mouse and 
the keyboard which felt wrong. Also, I did not think it was possible to keep an 
AT informed of which toolbar activity.

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

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.


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

[SNIP]

Padraig