Moving to the gnome-shell component, as the window-menu.js building the menu is part of gnome-shell.

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.

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 ...

This sounds like a regression to me, we should start thinking about mnemonics in shell for the next iteration

(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.

(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?

Renaming bug for clarity

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.

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 :)

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

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

(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

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).

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.

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

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.

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!

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

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

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?

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

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.

What rationale could there be for _not_ including this feature and breaking users' muscle memory?

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.

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 :-)

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.

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

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.

There's yet another report on gitlab.gnome.org: https://gitlab.gnome.org/GNOME/gnome-shell/issues/914

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

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.

(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.

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.

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!

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.

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.