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 572587 - gnome-terminal shortcuts: Alt+Shift+1 shows as Alt+! etc
gnome-terminal shortcuts: Alt+Shift+1 shows as Alt+! etc
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
3.22.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
: 737644 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-02-20 19:13 UTC by Pedro Villavicencio
Modified: 2018-05-02 14:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pedro Villavicencio 2009-02-20 19:13:10 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,
Comment 1 Christian Persch 2009-02-20 19:25:32 UTC
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.
Comment 2 Matthias Clasen 2014-12-07 22:26:45 UTC
*** Bug 737644 has been marked as a duplicate of this bug. ***
Comment 3 Olliver Schinagl 2014-12-08 07:46:25 UTC
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).
Comment 4 Daniel Boles 2017-09-18 10:43:49 UTC
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.
Comment 5 GNOME Infrastructure Team 2018-05-02 14:40:58 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/313.