SUMMARY When trying to use the keypad numbers (0-9 with NUM lock on) to trigger keyboard shortcuts in the window actions menu, nothing happens. It works well with number keys from the keyboard top row. This issue is detected on X11, I have not tested it with Wayland. STEPS TO REPRODUCE 1. Make sure NUM lock is on. 2. open the window action menu by right clicking the window title bar, left clicking the application icon in the window title bar or hitting the keyboard shortcut for window action menu (ALT-F3 by default). 3. Use the keyboard arrows or letter shortcuts to open the sub-menu for "Move to Desktop" or "Move to Screen" 4. Use one of the keypad number buttons to trigger a numbered screen or desktop entry. OBSERVED RESULT Nothing happens EXPECTED RESULT The relevant menu entry to should be activated and the window moved to the selected desktop/screen. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu CI package kwin-x11-4:5.17.80+p19.04+git20191022.0539-0 KDE Plasma Version: 5.17.80 KDE Frameworks Version: 5.64.0 Qt Version: 5.12.2
On Wayland both numbers above letters and keypad numbers do not work. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.1
It is funny, for me on Plasma 5.23 (from the PPA) Kubuntu 21.10, under X, the oppositte happens - numpad works but the number from the row above the letters do not. No matter if I set super, alt or ctrl as the modifier.
*** Bug 446389 has been marked as a duplicate of this bug. ***
The new subject seems counter-intuitive: the original issue is that kwin does indeed differentiate between numpad keys and standard number keys - if you try to use the numpad numbers to access menu accelerators you'd find they do nothing. But the other issue is also correct - the shortcut editor does accept numpad numbers in shortcuts and treats them to be identical to standard number keys, and when used - they work: i.e. numpad keys trigger shortcuts set with standard number keys and vice versa. Assuming that both are handled in kwin, this is confusing to me, and also I'm not sure what is the correct behavior - numpad keys are a useful shortcut to find the correct number key without looking (they are better arranged for that) so I would like to use them for pre-set actions that cannot be customized - like menu accelerators, but I also understand why people would want to use them for different global shortcuts than standard number keys. I think this all boils down (again, like a few other reported bugs, e.g. bug 453661, bug 444537 and bug 470256) to the fact that global shortcuts should use the concept of physical keys (i.e. what is the position of the key that was pressed on the keyboard) while things that look like typing text (e.g. menu accelerators) should use logical keys (i.e. what character a key generates based on the software configuration) - though it looks like currently it is the reverse. As in the bugs mentioned above, I blame Qt. As to bug 446389 - I do not think it is an actual duplicate. It may be closely related, though I'm not familiar with what implements these two - quite distinct behaviors - so I'll defer to Nate's opinion.
Sorry, my bad. Re-titling.
(In reply to Oded Arbel from comment #4) > But the other issue is also correct - the shortcut editor does accept numpad > numbers in shortcuts and treats them to be identical to standard number > keys, and when used - they work: i.e. numpad keys trigger shortcuts set with > standard number keys and vice versa. Assuming that both are handled in kwin, > this is confusing to me, and also I'm not sure what is the correct behavior > - numpad keys are a useful shortcut to find the correct number key without > looking (they are better arranged for that) so I would like to use them for > pre-set actions that cannot be customized - like menu accelerators, but I > also understand why people would want to use them for different global > shortcuts than standard number keys. > I think a good design would be this: 1) If for a given number there is no separate action set for keypad key and for above-the-keyboard key, treat them as the same. 2) It there are separate actions, treat them separately. 3) When assigning shortcuts, treat above-the-keyboard keys as plain numbers and when using keypad number, ask the user if they want to use specifically keypad key that would apply to this key only or generic number that would apply both to it and the above-the-keyboard key. In practice, let's say CTRL+1 is set to "close a window" and nothing else is set. Both CTRL+1 and CTRL+KP1 close a window. Now I try to assign CTRL+KP1 to "close tab". So I am asked if I want to assign a separate action just for the keypad key or if I want to change the meaning of CTRL+1 from closing window to closing a tab. However, that would be a nice bonus, for start, making sure the shortcuts work for both above-the-keyboard and keypad keys would be great:-).
(In reply to Nate Graham from comment #5) > Sorry, my bad. Re-titling. Better, but this is not X11 only - as noted in the keywords field, I specifically have this issue on Wayland. I'm not even sure how it behaves on X11, it might be fine.
But in your original report, you said, "This issue is detected on X11, I have not tested it with Wayland." The person who added the "wayland" keyword was me, apparently in error.
(In reply to Nate Graham from comment #8) > But in your original report, you said, "This issue is detected on X11, I > have not tested it with Wayland." The person who added the "wayland" keyword > was me, apparently in error. Ok, so my bad then - I've been running on Wayland for almost a year - where I also have this issue - and got confused. I've just verified - the issue of numpad numbers not triggering the kwin window operation menu accelerators is apparent on both X11 and Wayland. The bug 446389 issue, as that was mentioned, BTW, is Wayland only - on X11 there's no problem setting up numpad shortcuts to differ from number row shortcuts.
It looks like this is caused by Qt not handling the numpad key codes: https://bugreports.qt.io/browse/QTBUG-94892