Mac-Style Keyboard Shortcuts on Ubuntu (GNOME + Wayland)

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, Super+Z, Super+F — all behave like Ctrl+C/V/A/Z/F, 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:

1. Log out and back in (not just lock the screen) — this forces a clean keymap reload.
2. 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.
3. 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 x11
loginctl list-sessions --no-legend
loginctl 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 ibus
gsettings get org.gnome.desktop.input-sources sources
ibus 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 application
gsettings 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

Key Takeaways

1. Don't swap keys, add a modifier — altwin:ctrl_win is additive, not destructive.
2. 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.
3. Test in a real text field, not a terminal — terminal Ctrl bindings mean something else entirely.
4. 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.