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.