GNOME Bugzilla – Bug 54047
KEYNAV: GtkToolbar
Last modified: 2011-02-04 16:16:03 UTC
Navigate in: Tab ... e.g. when the application menu bar is focused by pressing F10 (see bug #53544), pressing Tab would normally switch focus from the menu bar to the first application toolbar. Navigate out: Tab, Ctrl+Tab, Shift+Tab, alt+mnemonic of any other control in context. (Still slightly unclear to me exactly how toolbars should fit into the general Tab order of any given app-- I need to play with some Java apps, as they allow this!) Focusing toolbar should give focus to first enabled control on the toolbar. At which point: - left/right arrow key should move focus to previous/next control - Home/End should move focus to first/last control in toolbar - (Perhaps) Ctrl+left/right to move to first control in previous/next group of controls? (If so, should it be visual group or functional group?) - Post tooltip for focused control: Shift+F1 (see bug #53614) - Activate toolbutton - Enter [Check http://developer.gnome.org/projects/gap/keyboardnav.html for any later proposals that may not have filtered through to this bug report yet]
There seems to be a conflict between the navigation here (tab moves focus from menu to toolbar), and that in 53544 (tab moves focus among items in menu bar).
You're right, there is a bit of a conflict here. My personal inclination would be to remove the ability of Tab to move between menus on a menu bar, as there are two other ways of selecting menus already (left/right arrow keys, mnemonics). Instead, once a menu bar or toolbar has focus, have Tab cycle focus through each of the window's associated menu bar and toolbars in turn. Focus would then be returned to the other controls in the window by pressing Ctrl+Tab (and/or perhaps Esc?) whenever a menu bar or toolbar had focus.
There seems to be an assumption here that we must have a menu bar in order to navigate to the toolbar. Should there be a way to get to the toolbar if there is not a menu bar?
We certainly need that capability, yes. Two suggestions off the top of my head: 1. F10 focuses the first toolbar instead of the menubar, if there is no menubar 2. We have a different shortcut for focusing the first toolbar (Ctrl+F10 is free), whether there is a menubar or not. (In either case, Tab would still cycle through all available menubars and toolbars once a menubar or toolbar had focus). I think I prefer (1), if it's feasible-- it saves using up another accelerator combination. And at the end of the day, the toolbar doesn't really offer a huge advantage to keyboard-only users anyway, so making it super-accessible isn't a high priority (IMHO).
I am having terminology problems here; a toolbar cannot have focus so I assume that navigating into a toolbar is making a toolbar "active" and "selecting" the first enabled toolbar item. I assume that the approach will be similar to menus, i.e. a GTK grab will be done when a toolbar is made "active" so that keystrokes will be directed to the toolbar.
There is a reference above to "the first application toolbar". I assume that this should be "the first toolbar in the window". In any case, there is no support in GTK for multiple toolbars in a window, in the sense of identifying the first one and then finding the next one. I have attempted to implement some form of accessibility for toolbars. It will work for the case where a window has one toolbar. I am using <Ctrl>F10 as the toolbar accelerator. Pressing <Ctrl>F10 will activate the toolbar and select the first toolbar button. The left/right or up/down arrows will select the next/previous button in the toolbar. Home/End will select the first/last buttons in the toolbar. Selecting a button will display its tooltip if tooltips are enabled for the toolbar and the button has a tooltip. I describe the current interaction between mouse use and toolbar activation: 1) If the pointer was over a button in the toolbar when the toolbar is activated, the tooltip is popped down and the button is in prelight state. Clicking the mouse will activate that button; I have not found a way to intercept the event as it is sent to the button. 2) If the pointer is outside the toolbar, moving the pointer into the toolbar window will deactivate the toolbar.
Created attachment 5788 [details] [review] Provide some level of accessibility for GtkToolbar
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.
Created attachment 6486 [details] [review] New patch to provide navigability of Toolbars
Conclusions from: http://mail.gnome.org/archives/gtk-devel-list/2002-February/msg00372.html What I'm going to do is: a) Add a small standalone patch to make Control-Tab cycle focus between menu bars before 2.0.0. (But after 1.3.15.) b) Leave the full toolbar focusing issue and focus save/restore issues until after 2.0.0, probably for 2.2.0.
Menubar focusing patch applied as above: Thu Feb 28 19:57:03 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkmenubar.c (gtk_menu_bar_cycle_focus): Implement <Control>Tab <Control><Shift>Tab to cycle between all menu bars in a toplevel once one is up. * tests/testgtk.c: Add a second menubar, this example is already full of crack anyways. * gtk/gtkmenushell.c (gtk_menu_shell_key_press): Padd unhandled events up to the parent menu shell. * gtk/gtkmenuitem.c (gtk_menu_item_select_timeout): Only pop up the menu if the parent menu shell is still active.
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.
Padraig has a suggested patch in bug #87159 for proposed, more consistent keynav behaviour.
Owen: it's just been pointed out to me that Ctrl+F10 currently gives focus to a toolbar, I'd never noticed this before :/ I thought your recent F10-to-cycle patch was supposed to cycle through all available menus and toolbars and that toolbar keynav just wasn't implemented yet, but it seems I was wrong... So, is it your opinion that toolbar keynav is "implemented", and that we should close this bug and file separate ones against the current implementation (which does look rather buggy, especially if you float the toolbar)? Or is your intention to integrate toolbars into the F10 chain, which I think would be a preferable solution? Using Ctrl+F10 like this kind of breaks what we now use Ctrl+F10 for... although admittedly it didn't when I suggested it as one possibility last October :/ Yeah, I know, I really need to update those keynav docs...
I think what you are seeing is a Bonobo-specific patch ... I know that Michael was working on something like that. There is no support for keynav to Gtk toolbars. (So, if you see bugs in the toolbar keynav, they should be filed against bonobo)
Ah, I do believe you're right, thanks.
Moving various feature enhancements to the 2.4.0 milestone.
Owen: making this bug block #94856 because if toolbars are to be added to the F10 focus chain, bonobo will need some method by which bonobo toolbars can be added to that focus chain.
The current consensus is put the first item of each toolbar in the regular TAB focus chain. Then when a toolbar item has focus, the arrow keys move focus from around on the toolbar. For toolbar items that use the arrow keys for other purposes, GtkEntry mainly, Ctrl-TAB should move focus to the next toolbar item. When the toolbar has a handle, ie., is inside a GtkHandlebox, the first item on the toolbar should still get focus when you TAB into the toolbar, but then left arrow should move focus to the handle. Focus does not wrap around, and Home and End should work. The patch to EggToolbar that I am attaching implements basic keyboard navigation, but there are some implementation issues: - When the first item on the toolbar is focused and you press left arrow, focus should to the handle if there is one, otherwise the focus should not move. This implies that the left arrow keypress should be left unhandled by the toolbar so that the parent widget can move the focus to the handle. The problem is that if there isn't a handle, bug 60690 will move focus somewhere unpredictable when you press left arrow. So making this do something sensible depends on how bug 60690 is fixed - see my comments on that bug. If the fix for that bug is to actually fix the bug and make arrow keys wrap around correctly, then I don't see any non-hacky way to make arrows *not* wrap around for toolbars. Of course, hacks are not unheard of ... If the fix for bug 60690 is to make arrow keys not wrap around, then arrows will just work for toolbars. - The current GtkToolbar removes GTK_CAN_FOCUS from buttons to make them not focusable, and EggToolbar inherits that. I am not sure this is the right thing to do, and my patch doesn't do this. I'll suggest instead that we add a private _gtk_button_set_take_mouse_focus ( GtkButton *, gboolean) that will make GtkButtons not grab_focus() when they are clicked with the mouse. The alternative seems to be that the Toolbar on TAB in, walks its children and sets GTK_CAN_FOCUS on all buttons. If we do that, buttons will be focusable with the mouse whenever focus happens to be somewhere else on the same toolbar. [Please note that the patch is nowwhere near anything I'd want to commit, so don't bother reviewing it].
Created attachment 15157 [details] [review] Draft patch to add keyboard navigation to EggToolbar
Created attachment 15398 [details] [review] Patch that adds _gtk_button_set_take_mouse_focus()
I think the do-not-take-focus ability does make sense, but I'd make it a public facility, because I don't think there is anything that really makes it something that only builtin widgets should be able to do. As a public facility it should be done as a getter/setter/property triplet for consistency - (for bloat...) - rather than 'take-mouse-focus' as the name, maybe 'focus-on-click'
Created attachment 15402 [details] [review] new patch
Created attachment 15403 [details] [review] the header file
* Property shouldn't be G_PARAM_CONSTRUCT * Both doc comments have the wrong name in them * gtk_button_set_focus_on_click should check whether it's actually doing anything before sending the notification. (Small efficiency win, reduces a bit the possibility of infinite loops.) The standard boolean setter looks like: focus_on_click = focus_on_click != FALSE; if (focus_on_click != button->focus_on_click) { } * The double negative in the property description: _("If unset, the button will not grab focus when it is clicked with the mouse") is perhaps a bit confusing. I'd just say: _("Whether the button grabs focus when it is clicked with the mouse")
Created attachment 15404 [details] [review] new patch
Created attachment 15405 [details] [review] Another step towards the perfect focus_on_click patch
Indeed looks perfect to me now :-)
committed to HEAD
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
With new toolbar in CVS keyboard this bug can be closed.