GNOME Bugzilla – Bug 572587
gnome-terminal shortcuts: Alt+Shift+1 shows as Alt+! etc
Last modified: 2018-05-02 14:40:58 UTC
this report has been filed here: https://bugs.edge.launchpad.net/gnome-terminal/+bug/328444 "I use irssi a lot, using gnome-terminal. By default irssi uses Alt+num to change windows, gnome-terminal uses Alt+num to change tabs. When multiple tabs are open, Alt+num keypress is catched by gnome-terminal, so I decided to bind tab keys differently: Alt-Shift-1 -> Tab 1 Alt-Shift-2 -> Tab 2 etc. The keypresses function just fine, but they are displayed like this: Alt-Shift-1 -> Alt-! Alt-Shift-2 -> Alt-@ etc. (depends on keymap used) " "why is it wrong? same issue happens if you press Alt+Shift+ F for example you'll get a capital F instead of a normal one because shift key is pressed, and yes the key works as expected because is emiting the ! key press" "irst, having Alt-!, Alt-@ and so on in tabs menu is wrong, and it doesn't let the user follow the logic "1 for first tab, 2 for second tab" etc., instead it makes the user look for the non-numeric characters, causing confusion among non-exprerienced users. Second, have a look at eg. New Tab and Close Tab shortcut entries - Ctrl-Shift-T and Ctrl-Shift-W are given. My point is that if a shortcut requires pressing Ctrl, Shift and number 1 keys, they should be all displayed, instead of the character some combination may give and not including one or more required keys! Does this behaviour occur in any other Gnome programs? At least Gnome's own shortcut manager application shows Alt-Shift-1 as Alt-Shift-! which is not as bad but not right..." Thanks,
The same happens in gtk+/tests/testaccel (GtkCellRendererAccel) and with in-place menu-editing, so it's a general gtk+ thing. Re-assigning to gtk+; probably NOTABUG.
*** Bug 737644 has been marked as a duplicate of this bug. ***
From a pure user point of view (pure going from the gnome keyboard shortcut setup page) this is certainly something needing to be addressed. True, it is only a display issue; but it looks weird (and wrong).
I think the issue is that by the time the accelerator is stored anywhere in GTK+, such shifting has been baked-into the keyval, so you're only ever going to get a shifted keysym back out. Presumably we would need a way to determine whether the accelerator was originally specified as e.g. Shift+1 or !, and to display it accordingly. That might be non-trivial.
-- 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/313.