At least on the german (no dead keys) layout, remapping Desktop Grid shortcut to Meta+^ would make it untogglable. All meta-combinations I tried and many others have failed as well. Meta+1, Meta+2 etc as desktop switching shortcut works, but it fails as desktop grid toggle. (The left windows key is meta here) Tested on 2 arch systems, including rebooting after setting new shortcut - no luck. Reproducible: Always Steps to Reproduce: 1. Make sure Ctrl-F8 triggers desktop grid properly 2. Go to settings->desktop behavior->effects->desktop grid, click settings and set shortcut to Meta+^ 3. Click apply/ok. 4. Try using Meta+^ Actual Results: Nothing happens Expected Results: Desktop grid should appear German (no dead keys) layout.
What happens if you assign a Meta modified shortcut to eg. a) Present windows b) Switch to next desktop (maybe end up in second next, ie. 1 -> 3 instead of 1 -> 2?) Is Meta your kwin modifier (ie. Meta+Tab would switch between windows rather than Alt+tab)?
Sorry for not testing it thoroughly enough, i've experimented with sortcuts and it does seem to be a general shortcut issue. In general, any meta+English-Alphanumeric combination will work for any shortcut, but any Meta+[special- or nonenglish symbol] will produce a not working shortcut, eg Meta+O and Meta+0 works but Meta+Ö (german O-Umlaut) or Meta+^ doesn't. PS I use Alt+Tab for switching windows, didnt modify any stock shortcuts but the following: - Alt+Shift for layout switching (german/russian) - Meta+1 ... Meta+4 for desktop switching (works) - CapsLock behavior to "additional ESC"
Got it: it's a general keyboard layout issue: in the german layout the Z and Y keys are switched against US (quertz vs querty). If I assign a shortcut to Meta+Y (or Ctrl-Y or whatever) I can trigger it with Meta-Z (or Ctrl-Z). The shortcut editor in the system settings respects the keyboard layout, but the shortcut is triggered on US-Layout
do I get this right that you configured on German layout, but trigger on US layout? That's not going to work, it's based on the character representation not the physical key one presses.
I've configured German as my primary layout and Russian as secondary. (But I use US localization, no german translation) If I set to German layout (default), go to system settings->Shortcuts->Global keyboard shortcuts, select a shortcut, flip the radio button to "Custom", click on the shortcut recording button and press Meta+Z, "Meta+Z" appears as the selected shortcut. Then I click apply. When I then press Meta+Z nothing happens, while Meta+Y triggers the action I've assigned the shortcut to. I DO NOT change my keyboard layout in between.
Do you have a shortcut to toggle layouts? (And does it include meta? ;-) Just to narrow the issue: if you disable the second layout altogether, do things work as exected?
The shortcut is Alt-Shift ;) tried disabling the russian layout, nothing changed. Note that I do not use an english layout, only german. The shortcuts seem to be captured in the german layout but interpreted in the US layout. PS Just in case it matters, here is my localectl status: System Locale: LANG=en_US.UTF-8 VC Keymap: de X11 Layout: n/a
Hmmm. What happens if you restart kglobalaccel5 at runtime? $ pkill kglobalaccel5 $ kglobalaccel5 &
Restarting kglobalaccel5 right after setting up the shortcut does fix the problem. Seems like it then recognizes the german layout.
random finding: https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-30911
hmm, I'm rather thinking that it's related to kglobalacceld being started by dbusd and thus might be missing an env variable. Next time you start the system, please have a look into the environ of kglobalaccel5, especially for the LANG env variables, etc.
might be related to: https://codereview.qt-project.org/#/c/104506/1
*** Bug 343728 has been marked as a duplicate of this bug. ***
(In reply to Martin Gräßlin from comment #11) > hmm, I'm rather thinking that it's related to kglobalacceld being started by > dbusd and thus might be missing an env variable. I'm not aware that the keyboard map would be controlled by some environment variable? (In reply to Martin Gräßlin from comment #12) > might be related to: https://codereview.qt-project.org/#/c/104506/1 "If the window contains a widget that accepts text input..." ? "... a Meta+... shortcut will be interpreted as if no modifier was pressed." ? @Maverik This will setup a german layout "by default" ---- /etc/X11/xorg.conf.d/11-keyboard.conf --- Section "InputClass" Identifier "Keyboard Defaults" MatchIsKeyboard "yes" Option "XkbLayout" "de" Option "XkbVariant" "deadgraveacute" # Option "XkbModel" "microsofccurve2k" # probably not - wtf. does M$ no longer forge it??? Option "XkbOptions" "terminate:ctrl_alt_bksp,compose:caps" # nice to have Option "XkbRules" "xorg" Option "XkbKeycodes" "evdev" EndSection ------------------------------------------------------------------------------- You might have/want to adjust some options, but for a basic text it might show whether kglobalaccel simply misses the map change.
> "If the window contains a widget that accepts text input..." ? "... a Meta+... shortcut will be interpreted as if no modifier was pressed." ? my thought was that setting up the shortcut fails.
(In reply to Martin Gräßlin from comment #15) > my thought was that setting up the shortcut fails. >> The shortcut editor in the system settings respects the keyboard layout, but the shortcut is >> triggered on US-Layout Afaiu, the editor works exactly as expected - Maverick?
(In reply to Thomas Lübking from comment #16) > (In reply to Martin Gräßlin from comment #15) > > > my thought was that setting up the shortcut fails. > > >> The shortcut editor in the system settings respects the keyboard layout, but the shortcut is > >> triggered on US-Layout > > Afaiu, the editor works exactly as expected - Maverick? Yes - at least it displays the shortcut definition exactly as I'd expect it to.
*** Bug 344508 has been marked as a duplicate of this bug. ***
This works fine in Wayland with one caveat: You can't assign keys that are already assigned. For example, assigning Meta+1 doesn't work until you first manually unassign the default behaviour "Activate Task Manager Entry 1". However, this does fix the problem: Meta+Shift+1, Meta+Shift+2, etc can now be assigned and used as intended. As long as you're on Wayland, X11 still seems broken.
Meta+S was working for me in 5.19 and in early 5.20.* versions. Now it stopped working in: Operating System: KDE neon 5.20 KDE Plasma Version: 5.20.2 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Kernel Version: 5.4.0-52-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics 620
Should be fixed in Plasma 5.25.