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 733297 - Cannot use mnemonics in the window menu (and other shell menus)
Cannot use mnemonics in the window menu (and other shell menus)
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.15.x
Other Linux
: Normal minor
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
triaged
: 664403 681030 742470 750732 783728 790317 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-07-17 07:35 UTC by Ankur Sinha (FranciscoD)
Modified: 2021-07-05 14:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ankur Sinha (FranciscoD) 2014-07-17 07:35:13 UTC
gnome-shell-3.13.3-1.fc20.x86_64

Hi,

I just noticed that the keyboard short-cuts for the window menus don't work any more. As in, `alt spacebar` brings down the menu, but I cannot press 'z' to maximize the window etc.

Regression perhaps?

Thanks,
Warm regards,
Ankur
Comment 1 Robert Roth 2014-09-25 08:02:12 UTC
Moving to the gnome-shell component, as the window-menu.js building the menu is part of gnome-shell.
Comment 2 Matthias Clasen 2014-09-25 11:39:40 UTC
In case you need a workaround, Alt-F10 to maximize and similar shortcuts still work.

I don't think the shell has mnemonics in its menus anywhere, and I'm not sure we want to start introducing them now.
Comment 3 Florian Müllner 2014-09-25 12:08:10 UTC
If I remember correctly, Giovanni had a patch for mnemonic support in the app menu at some point, but it was turned down by the design team; so yeah, I don't think we are going to introduce them in the window menu now ...
Comment 4 Lapo Calamandrei 2014-09-25 12:33:11 UTC
This sounds like a regression to me, we should start thinking about mnemonics in shell for the next iteration
Comment 5 Jasper St. Pierre (not reading bugmail) 2014-09-25 14:24:54 UTC
(In reply to comment #3)
> If I remember correctly, Giovanni had a patch for mnemonic support in the app
> menu at some point, but it was turned down by the design team; so yeah, I don't
> think we are going to introduce them in the window menu now ...

The specific point was that we should have an app-specific help overlay showing all of the shortcuts. It's a neat idea, but we clearly haven't done anything with it.
Comment 6 Florian Müllner 2014-09-25 14:26:49 UTC
(In reply to comment #5)
> The specific point was that we should have an app-specific help overlay showing
> all of the shortcuts. It's a neat idea, but we clearly haven't done anything
> with it.

That would be shortcuts, not mnemonics - am I misremembering that there *also* was a patch for the latter?
Comment 7 Florian Müllner 2014-09-25 14:28:14 UTC
Renaming bug for clarity
Comment 8 Ankur Sinha (FranciscoD) 2014-09-30 19:00:53 UTC
Updating version to 3.14

I think mnemonics are a really handy tool to have, especially with the shell which is *awesome* to use when only using a keyboard. I use arrow keys to get to the required menu at the moment, but the mnemonics were more efficient (no need to move your hand to get to the arrow keys, single key press instead of multiple). It isn't too big a deal, just something that would be nice to have.
Comment 9 gnome-bugs 2014-11-18 06:26:11 UTC
Also, the keyboard arrows wrap around navigation is missing. When at the top item, pressing used to go to the last item. Super handy for doing close :)
Comment 10 Florian Müllner 2015-03-13 20:24:57 UTC
*** Bug 664403 has been marked as a duplicate of this bug. ***
Comment 11 Jasper St. Pierre (not reading bugmail) 2015-06-10 18:50:15 UTC
*** Bug 750732 has been marked as a duplicate of this bug. ***
Comment 12 Jasper St. Pierre (not reading bugmail) 2015-06-10 18:52:03 UTC
(In reply to Florian Müllner from comment #6)
> That would be shortcuts, not mnemonics - am I misremembering that there
> *also* was a patch for the latter?

This is extremely late, but you're not misremembering. It's bug #668046
Comment 13 Justin Garrison 2015-06-10 20:13:50 UTC
The window menu should have mnemonics that are independent from an app itself because the app shouldn't need to manage it's state for being "Always on Top" etc.

I would also agree that this is a regression because the mnemonics have existed in previous gnome-shell versions and afaik every other window manager (at least every other window manager I've used).
Comment 14 Christian Chapman 2016-05-22 05:50:38 UTC
Related, only arrow keys work to navigate the menu. PgUp/PgDn/home/end do nothing. 

The window context menu behaves very little like a genuine context menu and is very irritating to use without this basic functionality. Now you have to memorize a bunch more keyboard shortcuts that don't work everywhere.
Comment 15 Florian Müllner 2016-10-14 14:21:38 UTC
*** Bug 742470 has been marked as a duplicate of this bug. ***
Comment 16 Iain Lane 2017-04-27 11:53:18 UTC
Can someone please finally confirm (possibly using the bug's status) if a patch to fix this would be accepted or not?

I would be happy to write one. As far as I can there is no mnemonic support anywhere in St, so that would have to be fixed at the same time.

I'm talking about the menu with Minimize/Maximize/… in it that you can access by pressing alt-space - hopefully some of the terms above are referring to this one too.
Comment 17 Ryan Hayle 2017-05-26 18:28:08 UTC
This is really critical.  It severely limits usability when you're used to quickly hitting "alt-space n/x," for example, or to resize a window.  I realise there are other shortcut keys available for most of these functions, but that is beside the point—they should both exist.  Learning new shortcuts takes time, and not having mnemonics on the menu doesn't have any advantage whatsoever.  No one is required to use them.  This is simply how people expect menus to work.  It seems like it would be such a *trivial* fix to this regression!
Comment 18 Florian Müllner 2017-06-13 08:08:43 UTC
*** Bug 783728 has been marked as a duplicate of this bug. ***
Comment 19 Florian Müllner 2017-06-13 08:21:06 UTC
*** Bug 681030 has been marked as a duplicate of this bug. ***
Comment 20 Alan Pope 2017-08-14 11:00:22 UTC
With the upcoming switch of Ubuntu from Unity (where this feature has always existed) to GNOME Shell (where it never has), it feels like a regression for Ubuntu users to suddenly find that the keyboard shortcuts for window management no longer work. Would someone please comment on whether a patch would be accepted to add this feature in?
Comment 21 Florian Müllner 2017-11-14 12:41:53 UTC
*** Bug 790317 has been marked as a duplicate of this bug. ***
Comment 22 Jan Tojnar 2017-11-14 13:05:45 UTC
This is an issue for users that cannot use mouse (older users with limited fine motor control, essential tremor, or similar problems). If the design team does not like enabling it globally, maybe an option in accessibility menu could be added? Though I do not see why it could not be enabled by default, with the hints only shown when alt key is pressed, and the option would just make it visible all the time.
Comment 23 Daniel Colascione 2018-02-19 21:31:29 UTC
What rationale could there be for _not_ including this feature and breaking users' muscle memory?
Comment 24 Nate B 2018-07-01 20:33:20 UTC
Oh man, I upgraded from Ubuntu 16.04 to 18.04 and lost one of my most-used UI features! 

For those of us who have to keep a foot in the MS-Windows world, it's really important to have common shortcuts. Especially for something that used to work cross-platform and it's now missing from the linux side, it feels like a penalty of awkwardness, whenever I switch to my linux machine. 

Also, these shortcuts have worked for twenty-plus years, so removing them is a confusing hit to some very-long-term muscle memory. Please add my voice to those requesting this. I can't fathom why it was removed.
Comment 25 John Pye 2018-07-04 10:32:45 UTC
This bug has been reported 8 separate times. It is clearly something that users want. I guess when the GNOME 3 generation of UI coders start developing RSI things will improve again :-)
Comment 26 Teppo Turtiainen 2018-07-04 11:25:02 UTC
I manage windows almost exclusively with the keyboard. Move and resize can be activated with Alt+F7 and Alt+F8, but I can't hit the F-keys reliably without looking, so I do Alt+Space & Down & Down & Enter for move and Alt+Space & Down & Down & Down & Enter for resize. I've been doing that dozens or hundreds of times a day ever since this feature was removed. I'd really like it if we could have Alt+Space & m and Alt+Space & r back.
Comment 27 Andreas Kern 2018-11-19 17:38:13 UTC
I'm still used to press 'alt+space' + 'x' to maximize a window because that way i don't have to move my finger away. hitting the arrow keys or the fn keys means to leave the home row.

also the behavior where it did show the window menu with keys underlined was very nice.

i'm adding this comment to get notified if this changes.

maybe it would already be a progress if this ticket get's assigned to the specific gnome-shell component in which this would have to be implemented
Comment 28 Edward Jiang 2019-02-02 20:00:54 UTC
I totally agree with Andreas Kern, alt+space X keeps hand in typing position. This is obviously is a regression.

I went through bug #668046, the level of arrogance shown by the "Designers" is mouth opening.

I am okay with newer designs, but not giving it at least an option to turn on some features back has been proven by history the dumbest thing a software can do.
Comment 29 Tom Most 2019-02-06 07:19:35 UTC
There's yet another report on gitlab.gnome.org: https://gitlab.gnome.org/GNOME/gnome-shell/issues/914
Comment 30 Andreas Kern 2019-02-11 15:47:38 UTC
I found a new workaround.
After reading the source for the popup window here 

https://github.com/GNOME/gnome-shell/blob/master/js/ui/windowMenu.js 

I found this line

```js
        menu.actor.navigate_focus(null, St.DirectionType.TAB_FORWARD, false);
```
I guess that's also the place to add the mnemonics. 
This line says that you can navigate with TAB.
I just did that and it works. 
so instead of `alt-space x` I now do `alt-space TAB space`.

not too bad
Comment 31 Tom Most 2019-02-13 06:39:36 UTC
I did a little research into fixing this last week. Here are my rambling notes:

    WindowMenu (in js/ui/windowMenu.js) subclasses PopupMenu
    WindowMenu calls this.addAction for each menu item
    PopupMenu (in js/ui/popupMenu.js) defines addAction
        addAction instantiates a PopupImageMenuItem (if there is an icon) or PopupMenuItem
            both of these menu items extend PopupBaseMenuItem
            there is also a menu item with a switch, I guess this is the same code that renders the accessibility menu
            maybe aligning the appearance is why they replaced the old menu that had mnemonics?
        addAction calls Popupmenu.addMenuItem with the menu item
    These menu items have no support for mnemonics (at least I can't find any)
    Keyboard behavior is in PopupBaseMenuItem
    Therefore generic mnemonics support would need to be added to PopupBaseMenuItem
    How do mnemonics work in non-English locales?
    Cursory searching reveals https://developer.gnome.org/gtk3/stable/GtkWindow.html#gtk-window-add-mnemonic
        So I guess they are window-scoped? That makes sense.
    Yes, popupMenu.js was originally extracted from the panel: https://gitlab.gnome.org/GNOME/gnome-shell/commit/7fbf8ae4c9888393de191b70b118ea20986c8803

    Wayland seems to be the original motivation: https://gitlab.gnome.org/GNOME/gnome-shell/commit/e7af257814b1b56a4cbd863c6f69699813a580dd
        > Jasper St. Pierre:
        > Window menus being GTK+ widgets has always been frustrating to deal with. Under Wayland, GTK+ is using the X11 backend, so the menus there pop up in the wrong place, don't take a grab, and are unstyled.
    Wonder if this still applies. Doesn't GTK+ support Wayland natively now?

    Okay, so how to mnemonics work in GTK in general?
        https://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-markup-with-mnemonic
        https://developer.gnome.org/gtk3/stable/GtkLabel.html#gtk-label-set-mnemonic-widget
        > The target widget will be accelerated by emitting the GtkWidget::mnemonic-activate signal on it. The default handler for this signal will activate the widget if there are no mnemonic collisions and toggle focus between the colliding widgets otherwise.

        Okay, so that's how it's supposed to behave. We shouldn't need to worry about the swapping bit for this menu.

    Big gotcha: gnome-shell doesn't seem to use GTK at all. Instead it draws everything with "St" seems to stand for "styled".
        https://developer.gnome.org/st/3.24/
        St it doesn't seem to have much in the way of features compared to GTK, no mnemonics support at all.
        Will need to completely reimplement this.

I won't be doing anything more on this, but maybe this will be useful in case someone comes along who will. Good luck.
Comment 32 Florian Müllner 2019-02-13 13:46:17 UTC
(In reply to Tom Most from comment #31)

>     Wayland seems to be the original motivation:
> https://gitlab.gnome.org/GNOME/gnome-shell/commit/
> e7af257814b1b56a4cbd863c6f69699813a580dd
>         > Jasper St. Pierre:
>         > Window menus being GTK+ widgets has always been frustrating to
> deal with. Under Wayland, GTK+ is using the X11 backend, so the menus there
> pop up in the wrong place, don't take a grab, and are unstyled.
>
>     Wonder if this still applies. Doesn't GTK+ support Wayland natively now?

Yes, it still applies. You are right that GTK does support wayland natively, and it actually already did so at the time of that commit.

But the window menu isn't provided by the application, it is provided by the window manager/compositor. On X11, the WM/compositor is a client to the Xserver (albeit a privileged one), so it can (to some extent) use a client toolkit like GTK.

On wayland the WM/compositor *is* the display server, so if GTK used the wayland backend, everything would fall to pieces when GTK tries to establish a connection to the display server (which means itself in that case, so the "server" cannot handle the request while the "client" waits for a response).

> "St" seems to stand for "styled".

"Shell Toolkit" actually, to make clear that it is private to gnome-shell and shouldn't be used by applications.

But you are right that mnemonics would need to be reimplemented, likely in ClutterText.
Comment 33 crohit 2019-02-15 21:11:05 UTC
somebody pls fix this bug. i am just not able to use gnome because of this. it is very painful to operate when touch typing. m happy to give bounty for this.
Comment 34 Edward Jiang 2019-03-13 22:38:44 UTC
Hi everyone, i've hooked up a quick fix extension to address the Alt+Space x issue. You can check it here:
https://gitlab.com/edwardrf/gnome-shell-menu-shortcut-extension

Feedbacks and pull requests are all welcomed!
Comment 35 Edward Jiang 2019-03-22 02:03:53 UTC
The extension is available at: 

https://extensions.gnome.org/extension/1695/menu-keyboard-shortcut/

Please let me know what are the shorcut keys you would like to add back.
Comment 36 GNOME Infrastructure Team 2021-07-05 14:19:52 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.