GNOME Bugzilla – Bug 784610
Pressing Alt in a menu (opened by mouse) should reveal mnemonic underlines
Last modified: 2018-05-02 18:41:00 UTC
If a menu is opened by mouse, mnemonic underlines are not shown. Fair enough: I might be a user who doesn't care about keynav. However, users who do would expect that, based on the convention everywhere else, pressing Alt would reveal which, if any, mnemonics are usable in the menu. There should be a way to open a menu by mouse but then discover what keynav it offers. Pressing Alt _almost_ works for this , but only coincidentally: In fact, pressing any key activates "keyboard mode" and therefore triggers the underlines to be shown, even if the key is not otherwise consumed. However, the addition of the underlines doesn't take effect immediately. Instead, showing the underlines is delayed until the menu is redrawn, e.g. by moving the cursor over it. So, Alt is not handled specifically here; any keypress means 'enable keyboard mode' but doesn't cause a redraw to indicate this. I feel like a queue_draw() would be good if Alt specifically is pressed. That key is going to be people's first guess as to 'how can I see which mnemonics are available?'. At present, if the user has opened the menu by mouse but might be interested to know that keynav is also an option, they won't discover this, or get any feedback from Alt, unless they incidentally cause a redraw to occur. IMO the ideal would be to only show mnemonics while Alt is held down, as done by other widgets, but I'm not yet sure if this can work without conflicting with other key handling. So an immediate solution is just to redraw if Alt's pressed. A somewhat related issue is that the underlines are not reset when the menu is closed, so once you've opened with a key, or pressed a key in the menu then triggered a redraw, underlines are visible forevermore. That's not so bad - it's better always to see info than never(?) - but it contradicts how other widgets handle underlines, and seems to contradict this comment in gtkmenushell.c: /* The idea with keyboard mode is that once you start using * the keyboard to navigate the menus, we show mnemonics * until the menu navigation is over. I don't know, but maybe this behaviour of the menu is a consequence of how once keyboard navigation has begun in a window (illustrated by the focus rectangle being visible), there doesn't seem to be a way to turn it off.
(In reply to Daniel Boles from comment #0) > I feel like a queue_draw() would be good if Alt specifically is pressed. Hm, I can catch the keypress, but none of the gtk_widget_queue_*() on the menu or items don't seem to work, for whatever reason. Nor does also trying to force gtk_label_recalculate() by doing set_label(get_label()) on the items. It's possible to force GtkMenu to _always_ show its mnemonics, either on specific or all clicks, by altering the GdkEvent to set its button = 0 before passing it to gtk_menu_popup*() so that the menu forces itself into "keyboard mode". But that seems hacky. (Also, there doesn't seem to be any corresponding way to force mnemonics off later if desired, though again, I don't care too much about that.)
We don't show the mnemonics on Alt in menus since Alt-mnemonic does not actually work there.
Right, yeah, that makes sense. Do you know of any way that I could catch a keypress (probably best not to use Alt, of course) while the menu is open and make mnemonics visible that way? All keypress (not handled by a user handler) seem to trigger them being visible, but that's not actually shown until the cursor is moved for some reason. Also, are the underlines meant to go away later, or is it intended that they stay around forever once shown? The commentary in gtkmenushell.c is a bit ambiguous there (e.g. it might only mean they are hidden if a different submenu is opened; I'm on an old machine and having trouble finding any GTK+3 app with any submenus)
the cursor move _is_ what makes them visible, afair ? the menu keynav code is hairy and the mnemonic showing was a bit hacked together there, but from what I remember, the intention was that we decide upon seeing the first cursor move by keynav that menus are now in keyboard mode, and from then on show mnemonics until menus are dismissed.
(In reply to Matthias Clasen from comment #4) > the cursor move _is_ what makes them visible, afair ? Yeah, I should have chosen clearer descriptions. You're right that moving the selection cursor in the menu indeed shows mnemonics, like any key nav. What I meant to say was the mouse pointer, i.e. you can trigger underlines to show by this rather strange sequence: * Open the menu with a mouse button click * Press any key (which is not normally handled, e.g. Alt) * The mouse cursor is over the menu * Underlines are not shown yet * Move the mouse pointer (even slightly) * Underlines become visible I thought this was just because the redraw of the menu was delayed until the mouse cursor moved above it, but I couldn't seem to get any combination of queue_redraw() and friends to make the underlines visible, and I couldn't yet figure out what else was going on.
*** Bug 695775 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/849.