SUMMARY Global hotkey Shift+Win+2 is broken for me on layout switch to non-English with other Shift+2 symbol (english has @ there, my layout has ") in Wayland , it worked on X11. Wayland just tries to insert ". Specifically - it doesn't work only when there is active input focus, for ex. if input focus is on browser's url field, Shift+win+2 will be interpreted as shift+2 and " will be added in url field. If there is no active input field - global hotkey works. STEPS TO REPRODUCE 1. Set hotkey Shift+Win+2 on something (for ex - to open n'th desktop) 2. Open Kate, focus on input field, change keyboard layout to anything other that has different simbol on Shift+2 (instead on @) OBSERVED RESULT Kate will add this symbol as input. EXPECTED RESULT Global hotkey triggered. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux Testing (Bookworm) KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.4 Kernel Version: 5.19.0-2-amd64 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: RENOIR Manufacturer: HP Product Name: HP Pavilion Aero Laptop 13-be0xxx ADDITIONAL INFORMATION I've posted it in https://bugs.kde.org/show_bug.cgi?id=375518 , but looks like it's a bit different.
I cannot reproduce it in Plasma 6 when using Ukrainian keyboard layout. Shift+2 produces " too in UA layout.
(In reply to Vlad Zahorodnii from comment #1) > I cannot reproduce it in Plasma 6 when using Ukrainian keyboard layout. > Shift+2 produces " too in UA layout. I have a similar Wayland-specific issue on both Plasma 5 and Plasma 6. STEPS TO REPRODUCE: 1. Switch to the Ukrainian layout 2. Open multiple windows of some program 3. Press Alt+"Above_Tab" shortcut to trigger "Walk Through Windows of Current Application" Task Switcher action OBSERVED RESULT: KWin Wayland presumably expects specifically Alt+~ combination (and not Alt+ʼ which is produced with input using Ukrainian keyboard layout). As a workaround I can set Alt+ʼ as an alternative shortcut. On the X11 Session there wan't need in this.
I believe I can reproduce the issue on Plasma 6 RC1, my repro is using a different keys (because my non-English layout has the same shift symbols for the number row) but I believe it is the same issue. Reproduction using "/" key on Hebrew layout - in the SI-1452 the "/" key is on the left-most key of the top character row ("Q" in QWERTY layout): 1. Using the Shortcuts KCM assign some global shortcut to CTRL+/ (in my case I used the "launch Dolphin" shortcut). 2. Activate a window with a text input and put text cursor in the text input (for example, in Firefox on bugs.kde.org). 3. Switch to the Hebrew layout. 4. Press CTRL+/ Expected behavior: Dolphin should be launched. Actual behavior: Nothing happens (or some Firefox action might happen if it is bound to CTRL+.) On the other hand, pressing CTRL+Q (while in SI-1452 layout) does launch Dolphin. This is a **very** common issue and - depending on how you look at it - may not actually be a bug. This factors into the discussion in bug #355046: when creating a global shortcut with one layout, when another layout is active - should the global shortcut bind to the physical key on the keyboard or to the character emitted by the key in a specific layout. Bug #453661 (which Yevhen added a link from to here), is another instance of the same issue - though there its more about how to trigger global shortcuts bound to a character that isn't actually available in the active layout. But yes - I think these are all the same issue: IMO global shortcut (in contrast with app-specific shortcuts) should be bound to the physical key, though there are serious technical hurdles to implement this using the current Qt-based approach to global shortcuts.
Oded, in your case the behavior is probably consistent regardless if you have cursor in the text input or not? This bug is about non-Latin symbols, both "/" and "Q" are Latin.
(In reply to Andrey from comment #4) > Oded, in your case the behavior is probably consistent regardless if you > have cursor in the text input or not? Correct > This bug is about non-Latin symbols, both "/" and "Q" are Latin. I'm not sure I follow - so "/" is a Latin symbol, but "@" and double quotes are not? I have the exact same issue with "~" - I have it bound in a global shortcut and it does not work if the current window's active layout is SI-1452 - which maps ";" to the left most key on the number row. To me this issue seems a duplicate of bug #453661.
(In reply to Oded Arbel from comment #5) > (In reply to Andrey from comment #4) > > This bug is about non-Latin symbols, both "/" and "Q" are Latin. > > I'm not sure I follow - so "/" is a Latin symbol, but "@" and double quotes > are not? I guess, Andrey is referring to the issue that was described at https://bugs.kde.org/show_bug.cgi?id=375518#c47 I'll copy it here: > (In reply to Andrey from comment #46) > > Essentially, if a key produces different Latin symbol on other layout, the > > shortcut won't work (but it will if the symbol is not Latin). > > So basically: > - if my keyboard has non-Latin (e.g. Cyrillic) symbol on the same place as > the Latin symbol - shortcut will work > - If my keyboard has some other Latin symbol - shortcut won't work and I > will need to create another shortcut using different keyboard keyboard > > For me "Walk Through Windows of Current Application" is broken by default > since Ukrainian keyboard layout has another Latin symbol (apostrophe) on the > same place as QuoteLeft/Grave symbol.
(In reply to Yevhen from comment #6) > > For me "Walk Through Windows of Current Application" is broken by default > > since Ukrainian keyboard layout has another Latin symbol (apostrophe) on the > > same place as QuoteLeft/Grave symbol. OK, so for me its the same problem - the default shortcut for "Walk Through Windows of Current Application" is bound to the Latin mapping of the key known in ISO-9995 as E00, that in my non-Latin layout (SI-1452) maps to ";" (I've said as much in comment #5), and therefor that action doesn't work when the active application has the SI-1452 layout active. This problem does not depend on the active application having an active input field, and is actually bug #453661.
(In reply to Oded Arbel from comment #7) > This problem does not depend on the active application having an active > input field, and is actually bug #453661. The reason about distinguishing Latin vs. non-Latin characters - as discussed in the aforementioned bug - is that when kwin is trying to figure out if you triggered a global hot key or not, it uses a Qt logic that takes the symbol produced from the layout and tries to figure out "what is the Latin equivalent" because the model is "all global shortcuts are in Latin". If the symbol emitted is part of the Latin group, then the logic surmises that everything is fine and no translation needed. "apostrophe" and "semi-colon" are included in the Latin layout and therefor whatever shortcut is assigned to E00 will no work in Ukrainian or Hebrew layouts. OTOH, the global shortcut Meta+Q ("show activity list") that is bound to D01 will work in the Ukrainian layout because "й" is not in the Latin group, while it won't work in the Hebrew layout because the symbol it maps to D01 is "/" which is in the Latin group.