GNOME Bugzilla – Bug 53543
KEYNAV: GtkMenuBar
Last modified: 2011-02-04 16:09:56 UTC
Pressing the F10 key when there is a menubar available in the current context should give the menubar focus, indicated visually by highlighting the title of the first menu in the menubar (but *not* posting the menu). At this point: - pressing the left arrow or Shift+Tab should move the focus to the previous menu in the menubar, wrapping around if necessary, but not posting any of the menus in the process; - pressing the right arrow or Tab should move the menu focus to the next menu in the menubar, but not posting any of the menus in the process; - pressing the down arrow or Enter should post the currently-focused menu, moving keyboard focus to the first enabled item in that menu - pressing the mnemonic access character of any menu title in the menubar (including the one that currently has keyboard focus) should give focus to the next menu in the menubar with that access character. If the access character is unique amongst the menu titles in the menubar (as it normally ought to be), the menu is also posted, and keyboard focus is moved to the first enabled item in that menu - pressing Esc or F10 should remove keyboard focus from the menubar, and return it to the component that previously had focus. (Don't know if you can realistically implement returning focus to previous component at the gtk level; may just be a styleguide issue?) [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not have filtered through to this bug report yet]
Returning focus to previous component actually should work fine because menus keynav is not currently handled via the focus mechanism.
The function gtk_menu_item_mnemonic_activate() is called if the mnemonic access character for a menu title is pressed. The function calls gtk_menu_shell_select_item() if the mnemonic is unique and emits the signal "activate-item" if the mnemonic is unique. I will assume that the function gtk_meu_shell_select_item() should behave as Calum has described above, i.e. it should give focus to the next menu item with that access character; the change to gtk_menu_popup() will ensure that this happens without giving keyboard focus to menuitem in a submenu. The signal handler for "activate-item" should move the keyboard focus to the first enabled item in that submenu. As F10 should not activate the item the code in window_key_press_handler() in gtkmenubar.c will call gtk_menu_shell_select_item() instead of emitting "activate-item" signal. Using left/right arrow or Tab/Shift+Tab keys to navigate the menus in a menu bar and using down arrow or Enter/Return keys is implemented by adding keybindings to gtkmenubar.c The submenu associated with a menu item in the menu bar _is_ posted when the menu item in the menu bar is given focus.
Created attachment 5737 [details] [review] Patch to implement requested changes
This bug refers to a menu having focus. I am having difficulty with the terminology. In GTK a menubar, menu or menuitem cannot have focus. (From comments in gtktextmenushell.c) A menuitem can be "selected"; this means that it is displayed in the prelight state and if it has a submenu, that submenu will be popped up. A menu or menubar can be "active". For a menu this means that it is visible on screen. A menubar is not active until the user clicks on one of its menuitems. The current menuitem is the selected menuitem which is furthest down in the hierarchy. The current menu is the menu that contains the current menuitem. The current menu will always have a GTK grab and receives all key presses before the normal handling for a key press event is invoked. Instead of referring to a menu having focus we should speak of a menu being the current menu. I would like to reword the changes requested: Pressing the F10 key when there is a menubar available in the current context should make the menubar active and select the first menuitem in the menubar; this will have the effect of popping up the submenu but no menuitem in the submenu should be selected. Note that this is change from the current behavior where F10 causes the first menuitem in the submenu to be selected. This change will make the behavior of F10 the same as that of clicking on the first menuitem in the menubar. At this point: - pressing the left arrow should select the previous menuitem in the menubar, wrapping around if necessary; the submenu will be posted but no menuitem in the submenu will be posted. - pressing the right arrow should select the previous menuitem in the menubar - pressing the down arrow or Enter should select the first enabled item in the submenu corresponding to the currently selected menuitem in the menubar. - pressing the mnemonic access character of any menutitle in the menubar (including the currently selected one) should select the next menuitem in the menubar with that access character. If the access character is unique among the menuitem names in the menubar the first menuitem in the submenu is posted. - when the menubar is active pressing Esc or F10 should make the menubar inactive; this will return focus to the component which previously had focus. - Tab and Shift+Tab should have no effect when a menubar is active. This may be updated when we discuss how to access toolbars.
The attached change (10/01/01) to gtkmenubar.c is not adequate as a grab is not done on the menubar; this causes a problem when Escape of F10 is pressed. An updated patch which deal with that problem and which do not use tab keys to menu between menubar items is attached.
Created attachment 5785 [details] [review] Correct previous patch to gtkmenubar.c
[as discussed on #usability] I propose to use Alt (single press and release) instead of F10. Rationale: - To open a menu with the keyboard, the user already has to press Alt + some key. Hence, Alt is the more logical choice for activating the menubar. It is both easier to remember and easier to reach: the physical distance of the F10 key has to be taken into account. - In Windows and OS/2 at least, the response to pressing the Alt key is to activate the menubar. - If the Fx keys are left alone right now, they can be used in the future in a more consistent way. One can think of a GNOME-wide response to F1 'context sensitive help', F2 'Create a new text document', F3 'Open WWW browser' etc. Lastly, according to http://developer.gnome.org/projects/gap/keynav/gtk_menus.html , Alt is proposed as well as F10. Open for discussion: - if F10 is no longer used to activate the menubar, should an alternative be found for Shift+F10 (activate popup menu) as well? I think so - one possible suggestion: Alt+.
I wouldn't have any objections if Alt worked in addition to F10, however F10 is the standard on various platforms including Windows, Motif and Java, so it would be kind of foolish to ignore it altogether. Likewise, Shift+F10 is something of an unnoficial cross-platform standard for popup menus. Usability problems noted with the Alt approach in the past is that pressing a modifier key (or any other 'dead key') shouldn't generally perform an action, let alone put you in a mode. In the Windows implementation at least, the visual mode indicator (first menu title being highlighted) isn't at all obvious if you hit Alt by mistake, as it's not generally in the area of the screen you're working on at the time, and it can take a while to work out just exactly what's going on. Admittedly this could be improved by posting the whole menu (but leaving focus on the menu title).
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
I think the main (only?) remaining issue here is the request that F10 should focus the menu bar item, not the first item in the first menu bar (key focus on the menu bar should act as it does in the drop down menus where focus on the menu bar can be done without focusing any child items.) [ There is also the question of <alt><release> without any intervening events, but that is a little tricky to implement ]
Moving non-critical or hard to fix bugs to 2.0.2
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Sat Apr 6 06:57:00 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkmenubar.c: Select the first item on the menu bar for F10 rather than acting as if the user pressed <Alt>F to select the file manager. Resolving on the principle that any remaining issues in this bug report are lost in the noise ... I believe menus are basically working as desired.