http://bugzilla.suse.com/show_bug.cgi?id=783587
http://bugzilla.suse.com/show_bug.cgi?id=783587#c11
Egbert Eich
So, first of all, I think it would be very handy to disable this shift + numpad keys standard X behaviour in KDE. This should actually be rather feasible since other desktops do it, X keyboard config has such ano option,
This would be doable: You'd just have to add a file /usr/share/X11/xkb/types/numpad-mine with: partial xkb_types "mine" { type "KEYPAD" { modifiers = Shift+NumLock; map[None] = Level1; map[Shift] = Level2; map[NumLock] = Level1; map[Shift+NumLock] = Level1; level_name[Level1] = "Base"; level_name[Level2] = "Number"; }; include "extra(keypad)" }; and make sure, that the Xserver has: xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete+numpad(mine)" }; ^^^^^^^^^^^^^ xkb_compat { include "complete" }; xkb_symbols { include "pc+us(intl)+us:2+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; set. This however is not the expected behaviour and changing this globally for all users is not really what we want. Therefore you'd need to configure this for yourself.
Second, if possible, it would be really nice to be able to say "have numpad keys trigger their non-numpad keys equivalent codes". IMO it is the only way to make the numpad usable.
This doesn't sound like a good plan: X applications should be able to distinguish between 'normal' number keys and keypad number keys. Generally, I don't think it is a good idea to use a modifier key together with another key whose state is changed by the modifier key as hot key. Hot keys are for GUI toolkits to handle. In principle, xkb provides enough information to handle the hotkey situation correctly - even if a modifier used for the hotkey modifies the state of the other key. In any case, you might discuss this with the desktop projects. -- You are receiving this mail because: You are on the CC list for the bug.