After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 113458 - Distinguish between top-row and KP number keys when displaying accelerators
Distinguish between top-row and KP number keys when displaying accelerators
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 121597 124055 664219 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-05-21 16:58 UTC by Owen Taylor
Modified: 2018-05-02 13:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Owen Taylor 2003-05-21 16:58:20 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 
/*-+.
Comment 1 Sven Neumann 2003-09-07 15:34:04 UTC
*** Bug 121597 has been marked as a duplicate of this bug. ***
Comment 2 Marco Pesenti Gritti 2004-01-26 18:30:52 UTC
*** Bug 124055 has been marked as a duplicate of this bug. ***
Comment 3 Dave Neary 2004-09-17 09:59:28 UTC
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.
Comment 4 Owen Taylor 2004-09-17 16:00:54 UTC
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.
Comment 5 Mariano Suárez-Alvarez 2006-11-29 18:39:53 UTC
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...)?
Comment 6 Daniel Boles 2017-08-29 22:01:11 UTC
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.
Comment 7 Daniel Boles 2017-08-29 22:02:48 UTC
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.
Comment 8 Daniel Boles 2017-09-18 17:52:13 UTC
*** Bug 664219 has been marked as a duplicate of this bug. ***
Comment 9 GNOME Infrastructure Team 2018-05-02 13:48:10 UTC
-- 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.