Changing keyboard shortcuts in Gnome 40

I’ve just upgraded to Gnome 40 and I’m trying to change some keyboard shortcuts because of a combination of shortcut clashes and muscle memory.

  1. I can set “Move to workspace on the left” as Ctrl+Alt+Up and it works. But if I set “Move to workspace on the right” as Ctrl+Alt+Down then it doesn’t. I can’t see anything that it clashes with, but the shortcut just does nothing (no “you’re now on this workspace” or anything). Am I missing something, or is it a bug that I need to report with inconsistent shortcut behaviour?

  2. I use Alt+Super+Up/Down to play and pause music (because it’s nice and close to the other shortcuts, like moving desktops, and nothing used to use the Alt+Super combo). But now Alt+Super+Up takes you to the overview and then the app list. I can’t find the shortcut in the shortcuts list. Is there a way to override it?


It is the default shortcut for “Move to workspace below”. As workspaces now use a horizontal layout, the shortcut isn’t shown in Setting, so the conflict isn’t visible. It’s still a conflict though, which means that only one of the actions works.

You are not the first to run into this issue, and Settings will detect that conflict in 40.1.

Until then, you can fix it on the command line:

$ gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-down '[]'

Yes, similar as the above:

$ gsettings set shift-overview-up '[]'
$ gsettings set shift-overview-down '[]'

Those commands seem to have mostly fixed it. It looks like I also need gsettings set org.gnome.desktop.wm.keybindings move-to-workspace-down '[]' to stop the matching movement shortcut clashing.

Is the inconsistency of which one worked and which one didn’t purely an alphabetical ordering thing? Down comes before Right so it picks the first one and blocks it (because there is no “down” any more) but Left comes before Up and so it works.

I’ll see how I get on with up/down moving left/right. I might use gsettings to set both up/down and left/right and see what I end up using.


It’s either

  • the order in which gnome-settings-daemon grabs those keybindings
  • the order in which mutter reloads existing keybindings (for example on keymap changes)

But both implementations use GHashTable internally, so it boils down to the order in which hash tables iterate over elements. That order is explicitly documented as undefined.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.