GNOME Bugzilla – Bug 668046
Show accelerators in the app menu
Last modified: 2014-04-24 11:29:32 UTC
GTK shows them, and while we expect all apps to have the same accelerators for similar actions, those labels are handy to know which are actually wired up. Easy patch coming.
Created attachment 205397 [details] [review] RemoteMenu: show the accelerator next to each menu item The fallback GTK menu shows it, and it can be useful for knowing which accelerators are available. It uses the gtk-only 'accel' attribute from GMenu.
Could we be smart about this for the touchscreen case, and avoid showing the accelerators if there isn't a keyboard attached?
No, I don't think we want them to be shown. Menus are not a good way to advertise them or to learn about them, many/most useful shortcuts are contextual and not global, they are visually distracting, and we want to use a different and more complete way to display/learn about shortcuts: https://live.gnome.org/GnomeOS/Design/Whiteboards/HelpOverlay
(In reply to comment #3) > No, I don't think we want them to be shown. Menus are not a good way to > advertise them or to learn about them, many/most useful shortcuts are > contextual and not global, they are visually distracting, and we want to use a > different and more complete way to display/learn about shortcuts: > https://live.gnome.org/GnomeOS/Design/Whiteboards/HelpOverlay I'm not sure I agree with this design - or the assumptions behind it, actually. To be explicit: I disagree that menus are not a good way to advertise it. As I see it, the pattern is: - user needs to perform an action for the first time - he opens the menu and starts hunting - the action is found, user remembers the menu and position - then he needs to perform the same action again and again - he is still acting through the menu item - he sees that there is an accelerator available and starts using it - if at any time he forgets it, he'll fallback to the menu and find it again At no point the user says, "hey, maybe there is a keyboard binding for this action", which is a prerequisite for actively opening a cheatsheet or a manual, since he knows the action is somewhere in the menus, and for seldom used actions, this is undoubtedly faster.
What "menus" are you talking about? There is no hunting in the app menu.
(In reply to comment #5) > What "menus" are you talking about? There is no hunting in the app menu. I'm referring specifically to Epiphany here, which has a normal sized menu (8 items) and, contrasted with Documents or Contacts, actually offers useful functionality there, beyond About and Quit. Also, I'd consider wrong to treat the app menu any differently from a regular menu. It is a container for actions, and it is part of the random search one employs trying to do something with the app. If any, it needs more care, because it is often far from the window (not the case of Epiphany or Documents, which are usually maximized, but definitely of Contacts or Nautilus), so making the keyboard replacement more discoverable would help.
Honestly this argument makes absolutely no sense to me. Of those 8 items in Epiphany there will be 2 fewer soon. Those are not even things that are frequently used. And displaying shortcuts for infrequently used things is really dumb. If shortcuts are so important to display visually for learning then isn't it a problem that the most important ones won't even be in menus? Yes.
Closing WONTFIX
*** Bug 728837 has been marked as a duplicate of this bug. ***