Bug 415289 - Keyboard/mouse shortcuts should map to either keycodes or charcodes
Summary: Keyboard/mouse shortcuts should map to either keycodes or charcodes
Status: CONFIRMED
Alias: None
Product: frameworks-kwindowsystem
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks: 434988
  Show dependency treegraph
 
Reported: 2019-12-17 15:10 UTC by skaumo
Modified: 2023-08-08 13:19 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description skaumo 2019-12-17 15:10:52 UTC
SUMMARY
Keyboard/mouse shortcuts currently map to high level character-combinations only E.G.: CTRL-A or META-Ж, ALT-BTN5

If more than one keyboard layout is used on a system this causes usability problems.


STEPS TO REPRODUCE
1. Set up multiple keyboard layouts (E.G. US English and Russian)
2. Set the switching policy to "window" (this is optional, but amplifies the problem)
3. Configure some global shortcuts, E.G.: META-$ on a US layout
4. Switch to the Russian layout
5. Hit the shortcut defined in step 3


OBSERVED RESULT
The shortcut won't run.
META-$ on a US keyboard maps to META-SHIFT-4, but on a Russian layout that maps back to META-;


EXPECTED RESULT
The specified keyboard shortcut should always work, in every keyboard layout.


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 


ADDITIONAL INFORMATION

Important note:

Keyboard shortcuts should not always be mapped as above.
There are certain known situations, in fact, when users do expect them to map to keycodes(keysyms).
This is the case for CTRL-z and CTRL-y, for example for undo/redo operations.
QWERTZ vs QWERTY layout users really mean CTRL-z to match the character, not the keycode, even if they use both and switch between them.


However, for non language or typing related actions, other combinations may be assigned to some window-management action, like running an application or switching a desktop, in which case is indeed the keycode, and not the character, which should be used.



This means KDE system settings should allow to define shortcuts and ask whether they should match characters or the physical keys on the keyboard/mouse/other input device.

A dropdown box could let the use specify the type of matching they want for the given shortcut.

Match [ Key Symbol  [V]]
       |              |
       | Key Symbol   |
       | Physical Key |
        --------------


The same applies to mice/gaming mice and other buttons from input devices
There are some gaming mice which internally map button 6 to PGUP, then have another operating mode in which button 6 becomes BACK.
This is another case when it is desirable for some shortcuts to be defined against the low level keycode, so they just work independently of the mode the mouse is currently set up.
Comment 1 Andrew Shark 2023-08-07 07:09:00 UTC
I can confirm. Also possible to reproduce with "?" symbol.
1. Switch to US layout.
2. Set the KCalc launch shortcut to "Meta+?". It is pressed as Meta (Win) + Shift + "? /" (button near right shift).
3. Press Meta + Shift + "? /" - KCalc was launched normally.
4. Switch to RU layout.
5. Press Meta + Shift + "? /" - KCalc was NOT launched.
6. Press Meta + Shift + "& 7" (The "?" is on the "& 7" button in RU layout) - the KCalc was unexpecedly launched.

Expected result:
At step 5, the KCalc SHOULD be launched.
At step 6, the KCalc SHOULD NOT be launched.

In other words, user expects the shortcuts are treated as always in US layout, despite the current layout may be RU.

Operating System: Arch Linux 
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Graphics Platform: Wayland