https://bugs.kde.org/show_bug.cgi?id=364712
Bug ID: 364712
Summary: custom hyper key shortcuts get partially garbled after
saving settings
Product: krita
Version: 3.0
Platform: Debian unstable
URL: http://i.imgur.com/pFgRekl.png
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: NOR
Component: shortcuts
Assignee: krita-bugs-n...@kde.org
Reporter: nmaghfurus...@gmail.com
When I set custom shortcuts that make use of the Hyper modifier and press Save,
I am unable to trigger the actions that I've defined Hyper key modifier
shortcuts for. Navigating back to my custom shortcuts, I see that the settings
didn't actually save as expected: Krita appears to have garbled or threw away
the "modifier" part of the shortcut.
(Also, the way the Hyper shortcut is displayed is very strange, but that is a
different bug. I believe it is beyond the scope of Krita as some other KDE
software also display Hyper key shortcuts the same way, see Additional
Information)
Reproducible: Always
Steps to Reproduce:
1. Use xmodmap to bind a keycode (eg the keycode for Caps Lock) to a Hyper
keysym (either Hyper_L or Hyper_R), then bind the keysym to an empty modifier
(mod3 is often empty). Confirm the keycode actually sends the Hyper keysym
using a tool like xev.
2. In Krita, define a keyboard shortcut for About Krita that uses the Hyper
modifier (like Hyper + a)
3. Save the new settings
4. Press the new keyboard shortcut for About Krita (whatever it is)
Actual Results:
Nothing, the About Krita window does not appear.
Expected Results:
The About Krita window pops up.
My copy of the Krita 3.0 binary is self compiled from the git repo.
I used xmodmap to make my Caps Lock key behave as a "Hyper" modifier key, the
Hyper key is essentially just another modifier, exactly like Ctrl and Alt: In
X, the following modifier keysyms are recognized: Shift, Ctrl, Alt, Meta,
Super, Hyper, and Mode Switch. These keysyms can be bound in many ways to the
following "modifiers": shift, lock, control, mod1, mod2, mod3, mod4, and mod5.
Generally the Alt and Meta keysyms are not distinguished and may even be bound
to the same modifier. Super is usually on it's own modifier, and oftentimes it
is the keysym that is sent by the Windows key. Hyper is almost always unbound
to any keycode, or at least not a keycode that can be sent by an everyday
keyboard, that same can be said for Mode Switch. Additional information on
xmodmap: https://wiki.archlinux.org/index.php/xmodmap
Below is my configuration. Hyper is on it's own modifer, and is bound to the
keycode for Caps Lock. Frankly I don't understand X enough to know why keysyms
like Alt and Hyper are not the "same thing" as modifiers like shift, lock,
mod1, mod2, etc. I'm not sure what those "modifiers" even are.
I've configured my keysyms and keycodes like so:
$ xmodmap
xmodmap: up to 2 keys per modifier, (keycodes in parentheses):
shift Shift_L (0x32), Mode_switch (0x3e)
lock
control Control_L (0x25)
mod1 Meta_L (0x40), Meta_L (0xcd)
mod2 Alt_L (0x6c), Alt_L (0xcc)
mod3 Hyper_L (0x42), Hyper_L (0xcf)
mod4 Super_L (0x85), Super_L (0xce)
mod5
https://doc.qt.io/qt-5/qkeyevent.html
Qt docs suggest that the Hyper modifier event isn't actually supported (no
mention of Hyper)
https://imgur.com/a/LFstj
The way Hyper is displayed in various KDE software is very strange, but unlike
Krita the Hyper shortcuts do actually work. I have never seen the symbol
before and have no clue what it is, and it seems to suggest that Qt indeed
doesn't actually know how to handle Hyper key events.
https://i.imgur.com/DLFoE8v.png
GIMP handles the Hyper key as expected. Even though it makes use of a different
GUI toolkit, I think it is also a good example for how Krita could better
handle the Hyper key.
--
You are receiving this mail because:
You are watching all bug changes.
