I'm using a EU (US + special keys) keyboard layout, but occasionally I switch to a greek layout to enter greek symbols. On X11 I used to use CTRL+ALT+K to switch to greek and CTRL+ALT+K again to switch back. On Wayland, I can use CTRL+ALT+K to switch to greek, but I can't switch back. Probably this is, because I now effectively enter CTRL+ALT+Kappa. I'm not 100% sure, how global shortcuts are supposed to work with foreign keyboard layouts, but especially in regards of the "switch keyboard layout" shortcut this is odd. Maybe CTRL+ALT+Kappa is simply missing as a trigger for the shortcut or KWin's handling should be different here.
On Wayland we use the actual keyboard layout. Which is something which in my opinion makes a lot of sense. If you enter ctrl+alt+k it's using the config printed on they keyboard and the user does not have to know where the k key is on the English layout. So this is in my opinion a huge improvement over X11. Especially as on X11 it was inconsistent or just broken. AFAIK on X11 global shortcuts just does not notice when the layout changes. If you would start with greek layout as primary layout, it should be also broken. Now the problem is tricky. Do you know whether there is a key in the layout which renders a "k"? Or whether the k key actually generates multiple keysyms? If it generated kappa and k, we could change the code to support all syms.
Same here with russian layout (which is obviously completely different from english). (In reply to Martin Gräßlin from comment #1) > Now the problem is tricky. Do you know whether there is a key in the layout > which renders a "k"? Or whether the k key actually generates multiple > keysyms? If it generated kappa and k, we could change the code to support > all syms. I suppose Greek layout just doesn't have a "k" symbol at all. Does such layouts even exist (where the same symbol is placed on the some place in one layout and on another place on second layout)? Can we just bind it not to the symbol but to key ("scan code") instead? (however, it might break if user attaches another keyboard...) Or just map everything to English layout? (it might be weird if user isn't familiar with latin alphabet) Or maybe iterate over all configured layouts and check if pressed key code corresponds to a shortcut on any of it?
Am 10. Februar 2017 21:01:10 MEZ schrieb Igor Poboiko <bugzilla_noreply@kde.org>: >https://bugs.kde.org/show_bug.cgi?id=375518 > >Igor Poboiko <igor.poboiko@gmail.com> changed: > > What |Removed |Added >---------------------------------------------------------------------------- > CC| |igor.poboiko@gmail.com > >--- Comment #2 from Igor Poboiko <igor.poboiko@gmail.com> --- >Same here with russian layout (which is obviously completely different >from >english). > >(In reply to Martin Gräßlin from comment #1) >> Now the problem is tricky. Do you know whether there is a key in the >layout >> which renders a "k"? Or whether the k key actually generates multiple >> keysyms? If it generated kappa and k, we could change the code to >support >> all syms. > >I suppose Greek layout just doesn't have a "k" symbol at all. Does such >layouts >even exist (where the same symbol is placed on the some place in one >layout and >on another place on second layout)? > >Can we just bind it not to the symbol but to key ("scan code") instead? Unfortunately not. It's all keysym based. >(however, it might break if user attaches another keyboard...) >Or just map everything to English layout? (it might be weird if user >isn't >familiar with latin alphabet) Requires the English layout to be part of the Keymap. So not a general solution. >Or maybe iterate over all configured layouts and check if pressed key >code >corresponds to a shortcut on any of it? In general I like this idea, but I fear it's technically not possible. I think the best solution would be to start translating the shortcuts.
Ctrl+Alt+K shortcut switches keyboard layouts from Ukrainian to Russian and from Russian to English in X11 but not in Wayland Distribution: KDE neon Developer Edition Kernel: 4.15.0-29-generic Plasma: 5.13.80 Apps: 18.11.70 Qt: 5.11.1 Frameworks: 5.48.0
*** Bug 365812 has been marked as a duplicate of this bug. ***
Does killing & restarting /usr/bin/kglobalaccel5 help? see: bug 350816
(In reply to Holger from comment #6) > Does killing & restarting /usr/bin/kglobalaccel5 help? > > see: bug 350816 Certainly not: this is Wayland and kglobalaccel is not used.
Related link to the same bug in Qt: https://bugreports.qt.io/browse/QTBUG-66497
*** Bug 407703 has been marked as a duplicate of this bug. ***
Could someone try it on other compositor? It's still not clear to me if it KWin or Qt bug
I've opened Qt bug report: https://bugreports.qt.io/browse/QTBUG-90611
Have you tried switching the order of layouts? In https://bugs.kde.org/show_bug.cgi?id=432367 I observe related issues that only occur if US layout is on position 1 in the settings screen and my custom layout is on position 2. However, when moving the custom layout to position 1 and US layout to position 2 fixes there are no problems. Note that the Layout Settings have Move Up/Down buttons to change layout order.
>> Or maybe iterate over all configured layouts and >> check if pressed key code corresponds to a shortcut on any of it? > In general I like this idea, but I fear it's technically not possible. Would it be a decent solution to allow the user to configure which of their layouts is used to interpret global shortcuts?
(In reply to Bharadwaj Raju from comment #13) > Would it be a decent solution to allow the user to configure which of their > layouts is used to interpret global shortcuts? Qt already handles this by searching for a Latin1 shortcut for a key unconditionally, it occurs in special private library: https://code.woboq.org/qt5/qtbase/src/platformsupport/input/xkbcommon/qxkbcommon.cpp.html#525 We are going to just link to that library so the behavior will be consistent.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/786
*** Bug 434949 has been marked as a duplicate of this bug. ***
*** Bug 318666 has been marked as a duplicate of this bug. ***
*** Bug 167428 has been marked as a duplicate of this bug. ***
*** Bug 252594 has been marked as a duplicate of this bug. ***
*** Bug 260260 has been marked as a duplicate of this bug. ***
*** Bug 176514 has been marked as a duplicate of this bug. ***
*** Bug 177321 has been marked as a duplicate of this bug. ***
*** Bug 182434 has been marked as a duplicate of this bug. ***
*** Bug 187730 has been marked as a duplicate of this bug. ***
*** Bug 320612 has been marked as a duplicate of this bug. ***
*** Bug 422329 has been marked as a duplicate of this bug. ***
Git commit 91f47c909237437e93ceb84326ae1eead0c3e3e7 by Andrey Butirsky. Committed on 05/04/2021 at 19:39. Pushed by butirsky into branch 'master'. fix global shortcuts for non-Latin symbols Re-use Qt's implementation of handling non-Latin layouts here For full ASCII range support (Alt+`, etc.) Qt needs to be patched still, see QTBUG-90611 M +2 -0 CMakeLists.txt M +1 -0 autotests/CMakeLists.txt M +83 -0 autotests/integration/globalshortcuts_test.cpp M +0 -21 autotests/test_xkb.cpp M +1 -0 src/CMakeLists.txt M +4 -5 src/input.cpp M +3 -2 src/keyboard_input.cpp M +26 -22 src/xkb.cpp M +5 -4 src/xkb.h D +0 -312 src/xkb_qt_mapping.h https://invent.kde.org/plasma/kwin/commit/91f47c909237437e93ceb84326ae1eead0c3e3e7
Note: For full ASCII range support (Alt+`, etc.) Qt needs to be patched still: [QTBUG-90611](https://bugreports.qt.io/browse/QTBUG-90611), fix: https://codereview.qt-project.org/c/qt/qtbase/+/339895. Without patched Qt, only alphabetical key shortcuts (on any layout) brought back to work.
*** Bug 309193 has been marked as a duplicate of this bug. ***
Good catch. Thanks! (still, please pay attention this bug is about global shortcuts)
(In reply to Andrey from comment #30) > Good catch. Thanks! > (still, please pay attention this bug is about global shortcuts) Yes, however the non-global i.e. application shortcuts problem is fixed as of now (tested on Neon unstable), and the only remaining part was the global shortcuts bit (fixed here).
Yes, that's because global and non-global ones are now using the same internal Qt function which handles this.
*** Bug 437043 has been marked as a duplicate of this bug. ***
*** Bug 441103 has been marked as a duplicate of this bug. ***
Dear all, This bug had been reported to be fixed over a year ago, but I am still experiencing it on all my installs. I opened a bug request (448154) five months ago, that was closed duplicate immediately, yet the bug remains, although I am running the latest Kubuntu with KDE backports. I am basically unable to use accented chars such as ç or é in global keyboard shortcuts, which makes a lot of my keys useless for <Ctrl>+key bindings. Can you tell me what the state is? Thanks a lot!!! Operating System: Ubuntu 22.04 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-37-generic (64-bit) Graphics Platform: X11
Johannes, please note the bug was filed for Wayland, please see if you still can reproduce the issue there.
You are right: I don't experience the bug in Wayland! Sorry that I did not realise that it was Wayland specific here! But that's not an honest point because several bug files that have been marked duplicate of this one imply X11, and were closed regardless. Besides, the bug isn't really a purely Xorg thing as accented keyboard shortcuts only break in KDE under Xorg, not in Gnome or Cinnamon using Xorg. I am therefore re-closing that one (sorry!) and will awake another one that is more Xorg specific!
Global hotkey Shift+Win+2 is still 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 ". 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
(In reply to George Melikov from comment #38) > Global hotkey Shift+Win+2 is still 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 ". > > 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 Ah, even more interesting - 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.
Please try on dirsto with patched Qt: https://community.kde.org/Qt5PatchCollection
(In reply to Andrey from comment #40) > Please try on dirsto with patched Qt: > https://community.kde.org/Qt5PatchCollection Looks like I already have this commit https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5/diffs?commit_id=d5955f471ef19686137b4f5f835d45fedc0eaa08 (Add patches from KDE's Qt 5 Patch Collection up to 2022-05-14) in my system https://packages.debian.org/bookworm/qtwayland5 , so it's reproducible on Qt5PatchCollection from 2022-05-14. Can't guarantee for 100% Qt5PatchCollection identity though.
(In reply to George Melikov from comment #39) > Ah, even more interesting - 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. Maybe it's a different issue then? Could you file it separately? The one here didn't work regardless of the focus.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
(In reply to George Melikov from comment #41) > (In reply to Andrey from comment #40) > > Please try on dirsto with patched Qt: > > https://community.kde.org/Qt5PatchCollection > > Looks like I already have this commit > https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5 You haven't, it's even wrong repo. Unfortunately, Debian applies KDE's Qt patches just partially. This is the source of many confusions, apparently. When I realized it, I immediately initiated inclusion of the patch in question but it happened just recently: it will be part of qtbase-opensource-src 5.15.6+dfsg-5. I also asked the Debian's Qt maintainer to apply all the patches in the future: https://salsa.debian.org/qt-kde-team/qt/qtwayland/-/merge_requests/5#note_358970 Please provide the feedback when you get the patch needed.
(In reply to George Melikov from comment #38) > Global hotkey Shift+Win+2 is still 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 ". Right, this case is still broken but has a separate report: bug 453661 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).
(In reply to Andrey from comment #46) > (In reply to George Melikov from comment #38) > > Global hotkey Shift+Win+2 is still 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 ". > Right, this case is still broken but has a separate report: > bug 453661 > > 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. Is there any hope to workaround it on the KDE side? I also wonder, why do we need a separate issue (https://bugs.kde.org/show_bug.cgi?id=453661) for this case. This issue is also about Wayland session but it's more noticeable and has more useful information.
(In reply to Yevhen from comment #47) > Is there any hope to workaround it on the KDE side? It was an attempt to solve that on Qt side once and for all but that was failed, read up from here: https://bugs.kde.org/show_bug.cgi?id=453661#c30 (In reply to Andrey from comment #37) https://bugs.kde.org/show_bug.cgi?id=453661#c37 > As the Qt fix was discarded, the focus was shifted to try to solve it on XKB > level: > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/416 If (and only if) that fails too, we could think about customizing KWin behavior, as a _very_ last resort. There is a hope but needs to be tested: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/428