| Summary: | Shortcut settings do not respect active keyboard layout. | ||
|---|---|---|---|
| Product: | [Applications] systemsettings | Reporter: | david |
| Component: | kcm_khotkeys | Assignee: | Michael Jansen <kde> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | adam.m.fontenot+kde, butirsky, cprise, jon.reeve, kermit, oded, scott.tancock |
| Priority: | NOR | ||
| Version: | 5.8.5 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
I also have this problem. In KDE4 (fedora 20) Shortcuts window I could press Ctrl-alt-S according to my layout and the same keys would work to trigger it. Now in KDE5 (fedora 23) Shortcuts when I press Ctrl-alt-S it shows up in the list correctly, but when trying to use the shortcut it triggers the Qwerty equivalent instead!!! It appears as if KDE4 used mapped input while KDE5 uses raw input. This bug could cause fairly serious problems, as it confuses user input for triggering functions. It should be acknowledged and fixed ASAP. I still notice the problem on some installations. For example, my current Kubuntu 16.04 install worked as expected, until I updated it to Plasma 5.8.5 and Frameworks 5.28.0 from kubuntu-backports. *** Bug 358547 has been marked as a duplicate of this bug. *** *** Bug 393520 has been marked as a duplicate of this bug. *** I can't reproduce on the latest release. Does anyone still see this issue? I do see a related issue: text typed using the "Send Keyboard Input" feature of a custom shortcut doesn't respect the active layout. I reported that here: https://bugs.kde.org/show_bug.cgi?id=444522 As far as I understand, the issue is that if you assign a global shortcut action to (for example) META + the left most letter key in the top most letter row, and then you have multiple keyboard layouts - the action is always triggered by META + the left most letter key in the top most letter row - regardless what character that key is sending in the current specific keyboard layout (when pressed without holding META) and regardless of the drawing that is painted on the face of the key. To me that seems like a feature, not a bug. I would grant that there are two ways to look at global shortcuts: 1) The letter used in the shortcut is the reminder of the action: META + N should open a [N]ew terminal. 2) The position of the key used in the shortcut is the reminder of the action: META+q to start activity switcher because Q is highly accessible and near the TAB key that is used for similar types of switching. That being said, when switching keyboard layouts multiple times during the session, expecting the physical position of the global shortcut key to change - this is not a desired behavior for most users and would be mostly confusing: that means you have to verify that you are in the expected keyboard layout before using a global shortcut. Also, because a very useful feature of Plasma is remembering the active layout on a per-application or a per-window, with that enabled (which I believe is the default) the position of where you need to put your hand to trigger a global shortcut will change by switching windows! Finally, this issue only affects X11 as of now (Plasma 5.26), as under wayland global shortcuts use the (IMO incorrect) behavior of binding to the character code sent by the keyboard layout input handler and not the physical keyboard scan code. As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now. Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again. Thanks for your understanding, everyone. The specific issue reported in this bug is not applicable to Plasma 6: When setting Colemak as the first (primary) layout, the global shortcuts reflect that layout - pressing META+N in Colemak (same key as QWERY's J, no K) will trigger the shortcut assigned on META+N regardless of which layout is actually active - which is working as designed. |
I use an alternative keyboard layout (Colemak), instead of QWERTY. It rearranges letters on the keyboard into positions more suitable for touch typing; for example, N is in the spot, where J is on QWERTY. I have set the layout as default in System Settings > Input Devices > Keyboard > Layouts; Switching policy is left as Global (default, I believe). However, global KDE shortcuts (I have tested KWin and Plasma Activities) do not respect the layout setting and reflect the default QWERTY letter positions instead. Reproducible: Always Steps to Reproduce: 1. Set keyboard layout to something different from QWERTY (e.g., Colemak). 2. Setup global shortcuts (Global Keyboard Shortcuts) specific to the keyboard layout. For example, I use Meta+N for "Quick Tile Window to the Left" and Meta+I for "Quick Tile Window to the Right" (in KWin). 3. Try to use the shortcuts in practice. Actual Results: The respective shortcuts are not recognized as per active layout. For example, Meta+N with Colemak does nothing, but Meta+K (Colemak K is in QWERTY N position) executes the configured action ("Quick Tile Window to the Left"). Expected Results: Shortcuts ought to reflect the active keyboard layout (set in System Settings or via setxkbmap), instead of being tied to keyboard scan codes or some defaults. I'm running Kubuntu 15.10 with KDE Frameworks 5.15.0 and Qt 5.4.2. Described behavior did not occur on Kubuntu 15.04 with kubuntu-backports (Plasma 5.3.2). Application Keyboard Shortcuts are unaffected.