After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 54047 - KEYNAV: GtkToolbar
KEYNAV: GtkToolbar
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
AP3
Depends on:
Blocks:
 
 
Reported: 2001-05-02 15:16 UTC by Calum Benson
Modified: 2011-02-04 16:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Provide some level of accessibility for GtkToolbar (20.41 KB, patch)
2001-10-08 16:24 UTC, padraig.obriain
none Details | Review
New patch to provide navigability of Toolbars (25.68 KB, patch)
2002-01-23 08:43 UTC, padraig.obriain
none Details | Review
Draft patch to add keyboard navigation to EggToolbar (11.65 KB, patch)
2003-03-21 20:44 UTC, Soren Sandmann Pedersen
none Details | Review
Patch that adds _gtk_button_set_take_mouse_focus() (2.51 KB, patch)
2003-04-02 19:27 UTC, Soren Sandmann Pedersen
none Details | Review
new patch (3.60 KB, patch)
2003-04-02 20:27 UTC, Soren Sandmann Pedersen
none Details | Review
the header file (3.07 KB, patch)
2003-04-02 20:29 UTC, Soren Sandmann Pedersen
none Details | Review
new patch (6.66 KB, patch)
2003-04-02 20:58 UTC, Soren Sandmann Pedersen
none Details | Review
Another step towards the perfect focus_on_click patch (6.87 KB, patch)
2003-04-02 21:20 UTC, Soren Sandmann Pedersen
none Details | Review

Description Calum Benson 2001-05-02 15:16:11 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]
Comment 1 Owen Taylor 2001-09-21 15:55:48 UTC
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).
Comment 2 Calum Benson 2001-09-21 16:15:26 UTC
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.
Comment 3 padraig.obriain 2001-10-04 09:18:18 UTC
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?
Comment 4 Calum Benson 2001-10-04 09:52:22 UTC
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).
Comment 5 padraig.obriain 2001-10-05 12:39:18 UTC
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.
Comment 6 padraig.obriain 2001-10-08 16:20:22 UTC
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.


Comment 7 padraig.obriain 2001-10-08 16:24:02 UTC
Created attachment 5788 [details] [review]
Provide some level of accessibility for GtkToolbar
Comment 8 Luis Villa 2002-01-22 21:30:13 UTC
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.
Comment 9 padraig.obriain 2002-01-23 08:43:34 UTC
Created attachment 6486 [details] [review]
New patch to provide navigability of Toolbars
Comment 10 Owen Taylor 2002-02-23 22:22:21 UTC
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.

Comment 11 Owen Taylor 2002-03-01 01:02:15 UTC
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.
Comment 12 Owen Taylor 2002-03-25 23:27:51 UTC
Moving non-critical or hard to fix bugs to 2.0.2
Comment 13 Matthias Clasen 2002-04-05 13:33:37 UTC
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Comment 14 Calum Benson 2002-07-17 10:34:51 UTC
Padraig has a suggested patch in bug #87159 for proposed, more
consistent keynav behaviour.
Comment 15 Calum Benson 2002-08-09 12:37:37 UTC
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...
Comment 16 Owen Taylor 2002-08-09 13:24:47 UTC
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)
Comment 17 Calum Benson 2002-08-09 13:29:34 UTC
Ah, I do believe you're right, thanks.
Comment 18 Owen Taylor 2002-10-24 16:49:34 UTC
Moving various feature enhancements to the 2.4.0 milestone.
Comment 19 Mark McLoughlin 2002-11-01 04:24:03 UTC
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.
Comment 20 Soren Sandmann Pedersen 2003-03-21 20:42:34 UTC
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].
Comment 21 Soren Sandmann Pedersen 2003-03-21 20:44:15 UTC
Created attachment 15157 [details] [review]
Draft patch to add keyboard navigation to EggToolbar
Comment 22 Soren Sandmann Pedersen 2003-04-02 19:27:49 UTC
Created attachment 15398 [details] [review]
Patch that adds _gtk_button_set_take_mouse_focus()
Comment 23 Owen Taylor 2003-04-02 19:52:29 UTC
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'
Comment 24 Soren Sandmann Pedersen 2003-04-02 20:27:36 UTC
Created attachment 15402 [details] [review]
new patch
Comment 25 Soren Sandmann Pedersen 2003-04-02 20:29:14 UTC
Created attachment 15403 [details] [review]
the header file
Comment 26 Owen Taylor 2003-04-02 20:36:03 UTC
* 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")

  
Comment 27 Soren Sandmann Pedersen 2003-04-02 20:58:31 UTC
Created attachment 15404 [details] [review]
new patch
Comment 28 Soren Sandmann Pedersen 2003-04-02 21:20:46 UTC
Created attachment 15405 [details] [review]
Another step towards the perfect focus_on_click patch
Comment 29 Owen Taylor 2003-04-02 21:26:07 UTC
Indeed looks perfect to me now :-)
Comment 30 Soren Sandmann Pedersen 2003-04-02 21:53:23 UTC
committed to HEAD
Comment 31 Calum Benson 2003-04-03 14:27:48 UTC
Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.
Comment 32 Soren Sandmann Pedersen 2003-06-30 19:57:12 UTC
With new toolbar in CVS keyboard this bug can be closed.