I'm not sure that should work; though if it isn't supposed
to work, you probably should be able to get to the other
menubar items with C/E/H rather than <Alt>C/<Alt>E/<Alt>H.

It should work, and indeed it does for me in Sun's beta 1 in every app
I tried *except* character map.  (If it's broken everywhere now, this
sounds like a fairly serious regression keynav-wise.)

Character map did have some other weird menu keynav problems though
(see point 2 in bug #87907)-- could this be related?  Gman claims to
have fixed this but, superstar though he is, he fixed it so quickly
that I'm not convinced he really got to the root of the problem :)

I took the latest sources (from CVS head) and I observed the above
mentioned problem in gnome-dictionary, gnome-calculator,
gnome-search-tool also. 

However, this problem is not present in case of eog and gedit, and it
is possible to select the menuitem by pressing the mnemonic even if
the focus is not present on any of the menuitems.
I have noticed that in these applications, the menu is created using
.xml files.

Hmm... well, whatever's causing it, we need to get to the bottom of
it-- this sort of inconsistency is a definite accessibility issue. 
Bumping up the severity/priority one notch accordingly, hope you don't
mind, Luis :)

I have had a look at what is happening in gnome-calculator and gedit.

In both cases, when the mnemonic is pressed on the keyboard a GdkEvent
of type GDK_KEY_PRESS occurs. The function gtk_propagate_event() is
called and as the event type is GDK_KEY_PRESS and the widget on which
the event occurred is a GtkMenu which is grab widget the event is sent
to the GtkMenu by the statement "handled_event = gtk_widget_event
(widget, event);". This causes a "key_press_event" signal to be
emitted on the GtkMenu.

In gnome-calculator, the default handler for the "key_press_event"
signal, gtk_menu_key_press() is called. This always returns TRUE so
the call to gtk_widget_event() returns TRUE. The event is handled so
no more processing of the event occurs.

The claim is that this behavior has changed since Sun Beta 1. Perhaps,
Owen can jump in here and suggest what has changed since the end of
May to cause such a change.

In gedit, we are using libbonoboui rather than vanilla GTK. When a
menu is created a signal handler sucking_gtk_keybindings_cb() is
connected to the key_press_event" signal for a GtkMenu. When the
"key_press_event" is emitted on the GtkMenu the function
sucking_gtk_keybindings_cb() is called before the default signal
handler.

This function calls gtk_menu_shell_key_press(), the default handler
for "key_press_event" signal for GtkMenuShell which returns FALSE. 
The signal emission is stopped so the default signal handler,
gtk_menu_key_press() is not called and sucking_gtk_keybindings_cb()
returns FALSE. Thus, gtk_widget_event() returns FALSE in
gtk_propagate_event(). As the event is not handled it is sent to the
top level window, which causes the mnemonic to be activated.

Acutally, it turns out this hasn't changed since Sun beta 1... I just
coincidentally happened to test applications that worked as expected! 
I can confirm that the behaviour is "broken" in calculator etc. on
beta 1 as well, but works as expected in gedit and EOG as Muktha said.

I doubt anything changed; it sounds like someone hacked
around a problem they saw with the GTK+ keybindings in
Bonobo, rather than trying to get the problem actually
fixed in GTK+.

Created attachment 10221 [details] [review]
Proposed patch

Any comments on the appropriateness of attached patch?

Padraig,

I have applied this patch on latest sources and found that it is
working as expected for many applications except for gnome-calculator. 

Steps:

1. Press F10. Gives focus to File menu. 
2. Press Q now. This will invoke the Quit button and closes the menu.
3. Next time, launch the application, press F10. It gives focus to
the    File menu. 
4. Now with Right arrow key, give focus to Help menu. Now pressing    
   C(mnemonic for Contents) should invoke the gnome-help OR        
   pressing A(mnemonic for About) should invoke the gnome about.
But      this is not happening.

I am just wondering why only gnome-calculator fails.?

The problem with gnome-calculator is that accelerators are defined in
gnome-utils/gcalc/gnome-calc.c for most of the first letters on the
buttons.

When you type a or c as in your test, the function
gtk_menu_shell_key_press() is called. As the menu shell does not have
an active menu item and does have a parent shell the key press event
is npased to the parent menu shell. This menu shell is the menu bar so
the accelerators defined on the main window are looked at.

Notice that when C is typed the value 0 in the calculators entry field
changes to 1 as the cosine has been calculated.

It looks like the mnemonics on the menu items in the first level menus
should not clash with the accelerators defined in the application. 

*** This bug has been marked as a duplicate of 94357 ***

Did you really mean to dup this, Bill? It doesn't look related.

If consistency ofg behavior is what is required I think that we would
be better off removing the function sucking_gtk_bindings_cb() from
libbonoboui.

We need to understand what the effect will be before doing it.

Padraig's patch I'd consider definitely wrong ... it happens
to work because it has the effect that if the key press isn't
handled at all, the default handler for the window gets
called which runs the mnemonics again. 

But that's not the intent of the code ... the intent
of the code is that all keypress handling happens in
gtk_menu_key_press and gtk_menu_shell_key_press -- 
mnemonics are already handled in gtk_menu_shell_key_press():

That's what:

  toplevel = gtk_widget_get_toplevel (widget);
  if (GTK_IS_WINDOW (toplevel) &&
      _gtk_window_activate_key (GTK_WINDOW (toplevel), event))
    return TRUE;

is for. (The code that is causing problems for gcalc)

The reason that it isn't triggering here is that we explicitely
set things up so that the domain of activation is the menushell
with the deepest selected menu item, not the deepest menu
shell. This is what:

  if (!menu_shell->active_menu_item && menu_shell->parent_menu_shell)
    return gtk_widget_event (menu_shell->parent_menu_shell, (GdkEvent
*)event);

in gtk_menu_shell_key_press() is for.

It would strike me as weird if the rules for what accelerators
are active are different for menu items in menu bras and menu
items with submenus in menu items. As I said at earlier:

 "...you probably should be able to get to the other
 menubar items with C/E/H rather than <Alt>C/<Alt>E/<Alt>H."

But I wouldn't expect to be able to select menu items in
the menus with the mnemonics when deepest menu selected
is the menuitem on the menu bar.

Why did you say "It should work", Calum? Just because it worked
in apps where Bonobo was in use? Or for useability reasons?

On most toolkits, the submenus won't be posted when you hit
F10, so you definitely wouldn't expect to be able to use
the mnemonics for the items in them.

*** Bug 82110 has been marked as a duplicate of this bug. ***

> Why did you say "It should work", Calum? Just because it worked
> in apps where Bonobo was in use? Or for useability reasons?

I said "it should work" because whenever the user sees a menu posted
on the screen, they should be able to activate one of its items by
pressing its access key-- that's just a fundamental expectation.

> On most toolkits, the submenus won't be posted when you hit
> F10, so you definitely wouldn't expect to be able to use
> the mnemonics for the items in them.

I think you've hit the nail on the head there... as you say, when you
press F10 on Windows, no menu is popped up, and only the access keys
for the menu titles are active.  I still think the way we do it is
more useful when it works as expected (i.e. as it does in bonobo
apps), but if the only way we can get it to work consistently is to
copy the Windows behaviour for both types of app then I guess I
wouldn't have a big problem with that either.

OK, my 2c worth:

If the mnemonic is displayed, it should work.  If it doesn't work, it
shouldn't be displayed.

From there I conclude that either 

#1) F10 should only focus the menubar but not post any menus, 

OR 

#2) F10 should post the first menu in the menubar and all mnemonics on
that posted menu should work (*not* the menubar).  

Of course whichever way we go, it should be consistent across the
desktop, especially vis-a-vis bonobo stuff.

Java does what Calum is suggesting (option #1); thus I would much
prefer sticking with that model, since otherwise we have inconsistency
(and thus accessibility problems).

-Bill

Correction: Java actually does mostly what we originally wanted to do,
i.e. option #2 :)

When you press F10 in Java, the first menu pops up but focus stays on
the title.  At this point the mnemonics on both the posted menu *and*
the other menu titles are available; I'm not sure which takes priority.

(Just adding comments in response to Owen's recent "what should we 
fix for 2.2" email)

I don't really have anything new to add, just that IMHO this is 
probably one of the more serious problems on Owen's list of things 
to consider fixing for 2.2, whether it be by implementing methods 1 
or 2 above or something else we haven't thought of yet :)

Calum is right, this is one of the more pressing UI issues in 2.1.X
relating to gtk+.  We feel that we urgently need a solution for
accessibility reasons, thus I believe we really need an agreed-upon
solution for 2.2.  We need at least to agree on behavior and create a
patch in the next couple of weeks, even if the final implementation
code differs from the patch's code.

*** Bug 93068 has been marked as a duplicate of this bug. ***

*** Bug 93068 has been marked as a duplicate of this bug. ***

There seems to be a desire for change here, but it isn't
clear to me what the desired behavior *is*.

Some implementation constraints for any 2.2. changes:

 A) If an item with a menu attached is selected (either an
    item on the menubar, or a menu item with a submenu),
    then the attached menu will be posted.

 B) Insensitive menu items cannot be selected.

Changing either of these is a significant amount of work
that is not feasible at the current time.

The current behavior is:

 Only the mnemonics in the deepest menu with a selected
 item are available.

Things I could do:

 1) Make the mnemonics on the menu bar work with Letter
    instead of Alt-Letter when navigating the menu. (Easy)

 2) Search some set of other menus _after_ the deepest
    menu with a selected item. (Easiest if the direction
    of searching is always upwards; searching menus
    deeper in the heirarchy would require bad hackery.)

    Typical conflict-resolution "cycle and don't select"
    is not doable for 2.2.

Neither of these actually solves the bug 93068, which seems
like the most urgent problem to me. I sense that there
are concerns about other issues here, but I'm really
not sure what those issues are.

To fix bug 93068, probably the easiest thing is to simply
go back on revisit the earlier decision:;

 - If the first item in the menu is not sensitive when
   the menu is activated, then focus the parent menu
   item for the menu.

and change that to:

 - If the first item in the menu is not sensitive when
   the menu is activated, then focus the next sensitive
   menu item.

Would that address the concerns here for now? Would the
combination of that and either of 1) or 2) address
the immediate concerns?

After some hacking and investigation of no-alt-for-menubar 
accelerators, I filed bug 101309. The code in there
works, but it's far too big (1000 line patch) and intrusive
to go in at this point for 2.2.0.

I made a simple (s/FALSE/TRUE/) change that should fix
the worst of the problems. We can investigate more 
ambitious changes for 2.4.

Sun Dec 15 18:14:16 2002  Owen Taylor  <otaylor@redhat.com>

        * gtk/gtkmenuitem.c (gtk_real_menu_item_activate_item):
        Pass TRUE for search_sensitive - prevents a problem
        where after hitting Alt-F to bring up the File menu,
        the mnemonics for the items in the menu might not
        be usable. (#89336)

The original problem reported in this bug is still present.

1) Run gnome-character-map.
2) Press F10.; the menu with items Browse and Quit are now visible.
3) The visible menu items Browse and Quit cannot be activated using
the keyboard.

From Owen's comments of December 9th, if the selected item of the
deepest menu with a selected item has a submenu would it be possible
to make the mnemonics in that menu available?

From Owen's comments I understand that the submenu will be posted.
Doing this would "require bad hackery" but I think that this is what
Calum and Bill are asking for in their comments of October 18th.

Any further action here needs to be done in a framework like
that discussed in bug 101309. I dont' think additional hackery
for 2.2.x makes sense.

I discussed with Owen on the possible solutions for this issue and the
available options as stated earlier above are:

a) F10 should post the first menu in the menubar and all mnemonics of
the posted menu should work (or)

b) F10 should only focus the first menu title in the menubar and
should not post the menu

From the discussions I guess implementing part-a will require fairly
large amount of code changes and complicated too. 


Owen suggested to try with part-b, IMHO I feel we should do the
following for part-b:

i)   F10 should focus the first menu title
ii)  Then either pressing space bar or down arrow should pop down the
menu
iii) Users should also able to pop down the menu by clicking on the
focussed menu title

What will happen if left or right arrow is pressed after using F10 to
focus the first menu title? Is focus moved to the next or previous
menu title without posting its menu?

> Is focus moved to the next or previous menu title without posting
its menu?

Yes, I think its should move around without posting the menu.

Yes, that's how it works on Windows IIRC.

Updating status_whiteboard field to reflect A11Y team's assessment 
of accessibility impact.

OK, this is marked as a "stopper" for accessibility.  We need to agree
on the behavior we need ( I think we have ) and we need an
implementation.  How can we move forward on this?  THis bug has been
around a long time... 

Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME
bug list :)

*** Bug 127418 has been marked as a duplicate of this bug. ***

owen - are you sure you really want to put this on 2.6.0?
there's been a patch for over a year (albeit one you consider wrong),
and this has been marked as an accessibility "stopper" for nearly two
years.  What are we doing wrong here?  Note also that the desired
behavior is the windoze behavior according to calum, and though we
don't want to take that as the gold standard, it does mean the
proposal isn't totally random.

correction - this was successively downgraded from "stopper" but from
calum's comments its apparent that this is pretty important and a
significant departure from other toolkits.

Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.

We have the mnemonic hash factored out now, so we have no-Alt-mnemonics working
if the focus is in the menubar, and it should be possible to make the mnemonic
resolution in menus look at mnemonics in multiple menus. We're probably not
going to get to that for 2.6.0, though.

Created attachment 35263 [details] [review]
make all menu mnemonics work

Here is a first attempt at making all displayed mnemonics work. 
Note that my patch does not try to construct a merged hash and
resolve conflicts across multiple menus. Instead, I look at the 
hashes of the current menu shell, an open submenu and the parent
shells (in that order), and cycle only between the matches in the 
first menu shell where the mnemonic is found. 
Cycling between matches across multiple menus might not work 
very well, since selecting a match in some other menu can affect 
the menu hierarchy, thus change the set of matches and cause 
cycling to "get stuck".

Regarding the lookup order in the patch, it might be better to
prefer matches in the open submenu over matches in the current 
shell, at least if the current shell is a menubar.

*** Bug 161751 has been marked as a duplicate of this bug. ***

After discussing this with Owen a bit, cycling should perhaps freeze changes to
the visual menu hierarchy. Items should be selected, not activated.

What does windoze do vis-a-vis cycling?  Remember, the most critical audience
for this feature will have preexisting expectations.

As far as I remember, Windows cycles only within the menu bar (i.e. between menu
titles with clashing mnemonics) when a menu title has focus, and only within the
most-recently posted menu when a menu has focus.  So it will never cycle between
a menu item and a menu title, for example.

Ah, as Owen is getting into GTK+,Cairo/win32 development, he can maybe test that
on his XP box...

We spent some time looking at the IE menu behaviour on Owens XP box, 
and observed:
- they have states where 
  a) mnemonics are shown but do not work
  b) mnemonics are not shown but work
- mnemonics only work in the innermost menu, even if the selected 
  item is in the parent menu
- cycling is done only within a single menu
- popup-after-timeout is done only with mouse navigation, never
  for keynav

What does that mean for us ? I think we should try the following
tweaks:
- restrict popup-after-timeout to mouse navigation
- make esc unpost the innermost menu instead of collapsing
  the entire hierarchy
- maybe make left-arrow unpost the innermost menu as well
- don't show underlines in menus where they do not work

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

After all this time, I think it is time to admit this won't be fixed