GNOME Bugzilla – Bug 113458
Distinguish between top-row and KP number keys when displaying accelerators
Last modified: 2018-05-02 13:48:10 UTC
Currently, GtkAccelLabel shows '1' for both GDK_1 and GDK_KP_1 for accelerator displays, but treats them differently. It should show 'KP 1' or '1 (Keypad)' or something like that. This also applies to the symbols on the keypad such as /*-+.
*** Bug 121597 has been marked as a duplicate of this bug. ***
*** Bug 124055 has been marked as a duplicate of this bug. ***
Wouldn't it be better for both keys to be treated the same? One expects KP + and + or KP 1 and 1 to produce the same result. It seems to me like the display is correct, and the behaviour should be changed.
Not sure ... traditionally certain types of applications have wanted all the the different possible accelerators they could get. With the predominance of laptops these days, whoeever, applications depending on a separate numeric keypad are fairly broken.
There are quite a few bugs where people complain that KP_1 is treated differently than 1 and so on; cf., among others, bug 380549 and bug 364566. Sometimes one can fix this by adding keybindings, but sometimes this does not work: for example, the terminal and metacity allow the user to set some keyboard shortcuts and most get surprised when choosing "Alt+1" does not include "Alt+KP_1". This would surprise people who change keybindings using gtkrc files for widgets too, I guess (but who does that?) Could gtk provide a gtk_accel_group_set_fold_keypad or something that apps call when they want to have the keypad treated the same as the ‘normal’ keys for that group (or even something that affects the complete app...)?
Yup, this is still an issue, both the lack of seeing which num key is which, and the lack of ability to target both by setting a single accelerator. (In reply to Mariano Suárez-Alvarez from comment #5) > Could gtk provide a gtk_accel_group_set_fold_keypad or something that apps > call when they want to have the keypad treated the same as the ‘normal’ keys > for that group (or even something that affects the complete app...)? For consistency GtkApplication, GtkShortcutLabel - and maybe more - would also need equivalent functionality for their accelerators.
I guess key folding should have its own bug, as that's new functionality, rather than clarification of existing stuff. I thought I saw a bug already for that, but I can't find it now. If none exists, it should get a new one.
*** Bug 664219 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/227.