SUMMARY If you have a keyboard shortcut like Alt+Shift for switching keyboard layout (which is also the Windows OS shortcut for 30+ years), the shortcut is also triggered when pressing Alt+Shift+N (KNote new Note), Alt+Shift+F2 (Krunner open with clipboard) or Alt+Shift+Up (used for move line up in some programs) STEPS TO REPRODUCE 1. In Settings->Keyboard->Layout dd a keyboard layout (unless you already have one) 2. In Settings->Keyboard->Layout click "Main Shortcuts" and select Alt+Space, apply 3. Press Alt+Shift+F2 to launch KRunner with clipboard contents OBSERVED RESULT The keyboard layout is changed, then KLauncher starts EXPECTED RESULT KLauncher should start without changing keyboard layout SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Debian 12+KDE KDE Plasma Version: 5.27.5 (and all other versions I used since 5.0) KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION In Windows, where Alt+Shift is the default keyboard layout, the layout switch does not happen when both keys are pressed, but rather afther both are pressed and Alt or Shift are **released**. This has to be intruduced to KDE as an option in order to prevent unwanted keyboard layout switching.
KWin doesn't do layout switching shortcuts, that's done in libxkbcommon - and this is a very old bug in it . See https://github.com/xkbcommon/libxkbcommon/issues/420 for more details
From what I understand, KWin is the one detecting the keyboard layout switch key combination: https://invent.kde.org/plasma/kwin/-/blob/529c3c29d300345219f3fcc173b3022c087bf32d/src/keyboard_layout.cpp#L52 The fact that the actual key translation is eventually done by libxkbcommon, and that libxkbcommon is involved with sending the two KEYDOWN events to KWin, do not necessarily mean that it should be the right place to resolve the problem. A resolution within libxkbcommon can only be done by trying to implement a heuristic that will prevent or delay sending the second KEYDOWN event, and maybe wait to see what is pressed next etc.. But: 1) It is a hack 2) It does not have the context of what shortcuts are being used and what overlap there is between them, if any (Only KWin has this information 3) Such a hack will have to be implemented also in Wayland 4) There are bugs for it in X11 for many years (see https://gitlab.freedesktop.org/xorg/xserver/-/issues/258) and will not be resolved I would really love to see KDE resolving this many years old problem, especially when Windows has the right behavior that is easy to learn from - responding to a modifiers-only key sequence only when any modifier key is released. + I would love to help with anything except coding (as my C++ is rusty, and I don't have the dev/debug environment)
The shortcut you linked is Qt::META | Qt::ALT | Qt::Key_K by default, not ctrl+shift
(In reply to Zamundaaa from comment #3) > The shortcut you linked is Qt::META | Qt::ALT | Qt::Key_K by default, not > ctrl+shift Sorry, my bad, I thought that some black magic is loading the config in addition to META+ALT+K Found the real black magic that loads the confik from ~/.config/kxkbrc and calls xkb_keymap_new_from_names
BTW, I still think that KWin should take over the custom keyboard switching shortcuts handling and support what Windows can. If I prepare a PR doing that, suppose it has an elegant implementation, will such PR be accepted, or this is a too radical change?
(In reply to zkdebugsk from comment #5) > BTW, I still think that KWin should take over the custom keyboard switching > shortcuts handling and support what Windows can. > > If I prepare a PR doing that, suppose it has an elegant implementation, will > such PR be accepted, or this is a too radical change? If it's possible to handle it ourselves and disable the thing in libxkbcommon, I think that would be a reasonable path forward