https://bugs.kde.org/show_bug.cgi?id=345816
h.goe...@crazy-compilers.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |h.goe...@crazy-compilers.co
| |m
--- Comment #10 from h.goe...@crazy-compilers.com ---
Maybe you need to rething whether only filtering "exiting" lock states is the
correct way. Maybe *all* lock states need to be filtered!?
- If there is a lock-state, but there is no key for locking/unlocking this
state, can this lock-state be meaningful at all?
- If e.g the Caps-Lock state should be ignored, why would it be ignored only if
there is a "CapsLock" key?
- Is there any case where some lock-state is meaningful for kglobalaccel?
- The X11 "level5_lock" (defined in /usr/share/X11/xkb/compat/level5 and used
by the "de(neo)" layout) adds another lock-state. Should this be filtered, too?
Why? Why not?
- Assume this example: "Alt+3" is defined as a short-cut
- Should "Shift+Alt+3" trigger this? According to [1] this would be the same
as "Alt+§" (German layout)
- Should "CapsLock+Alt+3" trigger this? According [1] CapsLock does not
change the "3", so this would be the same as "Alt+3".
- Should "ShiftLock+Alt+3" trigger this? According to [1] this would be the
same as "Alt+§" (German layout)
Now lets go on to the Numpad :-)
- Should "NumLock+Alt+KP_3" trigger this? According to [1] this would be the
same as "Alt+3".
Now let's assume some Level-X-Lock, where "Level-X + ." gives the symbol "3"
and "Level-X-Lock + ." gives the symbol "3", too. (This is what de(neo) does.)
- Should "Level-X-Lock + Alt+." trigger this?
To summarize: If all these cases would trigger the short-cut: Shouldn't all
lock-state be ignored?
[1] https://tronche.com/gui/x/xlib/input/keyboard-encoding.htm
--
You are receiving this mail because:
You are watching all bug changes.
