[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #5 from Oded Arbel --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #6 from Yevhen --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #7 from Oded Arbel --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274
--- Comment #8 from Oded Arbel ---
(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.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Andrey changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=375518 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Yevhen changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=453661 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274
Oded Arbel changed:
What|Removed |Added
CC||o...@geek.co.il
--- Comment #3 from Oded Arbel ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #4 from Andrey --- 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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Yevhen changed: What|Removed |Added CC||xalt7x.serv...@gmail.com --- Comment #2 from Yevhen --- (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. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 ezh changed: What|Removed |Added CC||eugene.savit...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 --- Comment #1 from Vlad Zahorodnii --- I cannot reproduce it in Plasma 6 when using Ukrainian keyboard layout. Shift+2 produces " too in UA layout. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 462274] global shortcuts do not work for non-Latin symbols of foreign keyboard layouts, if active application has active input field
https://bugs.kde.org/show_bug.cgi?id=462274 Nate Graham changed: What|Removed |Added CC||butir...@gmail.com, ||n...@kde.org -- You are receiving this mail because: You are watching all bug changes.
