Mac-Style Keyboard Shortcuts on Ubuntu (GNOME + Wayland)
·5 min read
Switching between a Mac keyboard habit and a PC keyboard layout is one of those small frictions that adds up over a workday — your fingers keep reaching for Cmd+C and getting nothing. Here's the setup I landed on for Ubuntu (GNOME, Wayland session) that fixes this without breaking anything else.
The Wrong Way to Fix This
The obvious-looking fix is to swap Ctrl and Super (the Windows key) entirely — so the key in Cmd's position just becomes Ctrl. Tools like xmodmap will happily do this. The problem: it's destructive. You lose the Super key's normal job (opening the Activities overview, Super+L to lock, workspace switching), and it doesn't match how Mac keyboards actually behave — Cmd and Ctrl coexist and do different things.
The Actual Fix: altwin:ctrl_win
GNOME (and X11/XKB in general) ships a built-in option that does exactly what's needed: it makes the Super key also send Ctrl, while leaving the real Ctrl key completely untouched.
gsettings set org.gnome.desktop.input-sources xkb-options "['altwin:ctrl_win']"
That's it — one command, no package installs, no app-specific configuration.
What changes:
Super+C, Super+V, Super+A, , — all behave like , everywhere: browsers, editors, file managers.
The physical Ctrl key keeps working exactly as before — terminal Ctrl+C (SIGINT), Ctrl+Alt+T, all untouched.
Tapping Super alone still opens the Activities overview, because that's a separate "overlay key" binding, not a modifier combo.
Verifying It Actually Applied
Check what's staged in dconf:
gsettings get org.gnome.desktop.input-sources xkb-options# → ['altwin:ctrl_win']
The One Gotcha: Wayland Needs a Fresh Login
On a Wayland session, mutter (GNOME's compositor) derives the merged keymap once at session start. Writing the setting via gsettings from a terminal updates the stored value immediately, but the running compositor doesn't always re-derive the live keymap from a bare CLI write the way it does when you change it through Settings → Keyboard in the GUI.
If Super+C doesn't do anything right after setting this:
Log out and back in (not just lock the screen) — this forces a clean keymap reload.
Test in a normal text field (a text editor), not a terminal — terminal Ctrl+C/Ctrl+V have special meanings unrelated to normal copy/paste.
Confirm Super still opens Activities on a solo tap — if it doesn't, something else (a different remap tool, a laptop firmware setting) is intercepting the key before it reaches GNOME.
Diagnosing "I Did That and It's Still Not Working"
If a relogin doesn't fix it, don't guess — check the actual session state before touching anything else:
# Are you even in the session you think you're in?echo "$XDG_SESSION_TYPE" # wayland or x11loginctl list-sessions --no-legendloginctl show-session <id> -p Type -p Active -p State# Did the setting actually persist to dconf, independent of gsettings' cache?dconf read /org/gnome/desktop/input-sources/xkb-options
If dconf read shows ['altwin:ctrl_win'] but the key still doesn't do anything, the next suspect is IBus — most Linux desktops route every keypress through it for input-method support, even when you're just typing plain English:
ps aux | grep ibusgsettings get org.gnome.desktop.input-sources sourcesibus engine # shows the *currently active* engine
On my machine this showed two configured sources — xkb:us and an Avro Bangla engine (ibus-avro) — installed for Bangla typing. The base xkb:us::eng engine is a pass-through and doesn't interfere, but it's worth ruling out explicitly: if the active engine at the moment of testing is a non-pass-through one, some engines maintain their own internal keymap state and won't reflect an XKB option change until the engine itself restarts (ibus restart or a full logout).
Going Further: Remapping GNOME's Own Shortcuts
altwin:ctrl_win only handles the "Ctrl-adjacent" shortcuts (copy/paste/undo/select-all/find). It doesn't touch GNOME's own window-manager bindings, which is the other half of "feeling like Mac" — Cmd+Tab for app switching, Cmd+Space for a launcher, Cmd+~ for cycling windows of the same app. Those live in a completely different settings schema and have to be remapped individually:
# Cmd(Super)+Tab → switch applications (GNOME already binds plain Super+Tab# to this in many versions, but make it explicit)gsettings set org.gnome.desktop.wm.keybindings switch-applications "['<Super>Tab']"gsettings set org.gnome.desktop.wm.keybindings switch-applications-backward "['<Shift><Super>Tab']"# Cmd+Space → open the app launcher (closest GNOME equivalent to Spotlight)gsettings set org.gnome.shell.keybindings toggle-application-view "['<Super>space']"# Cmd+` → cycle windows of the current applicationgsettings set org.gnome.desktop.wm.keybindings switch-group "['<Super>grave']"
These are independent, reversible gsettings writes — each one can be reset individually with gsettings reset <schema> <key> if it clashes with something you already rely on.
Why This Approach Over Others
Approach
Ctrl still works?
Breaks Super/Activities?
Setup effort
xmodmap full swap
❌
✅ (broken)
Manual, per-session
Per-app shortcut remap
✅
✅ (unaffected)
Tedious, app-by-app
altwin:ctrl_win
✅
✅ (unaffected)
One command
Key Takeaways
Don't swap keys, add a modifier — altwin:ctrl_win is additive, not destructive.
gsettings writes to dconf immediately, but GNOME's Wayland compositor may need a relogin to pick up a keymap change made outside the Settings GUI.
Test in a real text field, not a terminal — terminal Ctrl bindings mean something else entirely.
To undo: gsettings reset org.gnome.desktop.input-sources xkb-options.
Small friction, one-line fix — and it's the kind of change that pays for itself within the first hour of muscle memory.
