Keyboard shortcuts are affected by keyboard layout

I have bound “Window to Desktop 2” to Meta+Shift+2 in kwin, which the settings menu translates to Meta+@. If I now change my keyboard layout to German, I have to press the literal, awkward to reach Meta+@ and in general, all my other hotkeys for desktop 1 to 10 are now all over the place instead of on the number row.

Can I configure it somewhere so that my hotkeys are unaffected by the current keyboard layout and instead bound to fixed key positions?

I don’t think so, there is two way a keybinding system can work either it listen to keycode sent (given by evdev something like SHIFT+KEYCODE_2 not taking layout into account), but I think it is less common, or it listen to keysyms: the @ sent by keyboard+layout (xkb) wich is the case for kde shortcut system.
If you want something independant of layout use Meta+Alt+2 and avoid Shift unless alpha key.

here the answer on kde bug tracker
https://bugs.kde.org/show_bug.cgi?id=434988
(at the end)

I see. A bit unfortunate because I like shortcuts with shift. riverwm has this great feature where you can define for each shortcut in which keyboard layout it should be specified. When you then press a key, it will be looked up against the specified layout regardless of which one is active at the moment.

1 Like

Personally, I think this would be a useful option if it can be added without introducing too much complexity in the UI or underlying components.

As a past user of German keyboard layouts, I emphasize heavily with the pain that layout switching causes.

I believe I’ve just encountered this issue myself. I use a laptop with a QWERTY layout and a USB keyboard with a Dvorak layout so I have US and US (Dvorak) as my keyboard layouts. After a bit of experimentation it seems that KDE is actually always using the first listed layout in the “Configure Layouts” list for shortcuts. It’s definitely not a scancode issue because then the keys would actually stay the same (and I checked kglobalshortcutsrc in ~/.config and the config contains characters not scancodes).

I believe the issue is that kglobalaccel isn’t following the currently selected keyboard layout but it really should be.