GNOME Bugzilla – Bug 614146
Accelerator strings do not match key symbols with <shift> applied
Last modified: 2018-05-02 14:54:38 UTC
Created attachment 157297 [details] Brief program which reproduces the bug When setting up actions with GtkUIManager, it seems that the accelerator "<ctrl><shift>slash" doesn't work, even though similar accelerators such as "<ctrl><alt>slash" do. I have checked that this key combination is not bound to anything else on my desktop, but of course I may have missed something. Therefore, I have prepared a short test program to make the bug easy to confirm. There are two menu items in the program, bound to "<ctrl><shift>slash" and <ctrl><alt>slash". Selecting either menu item with the mouse will change the label text in the window. Pressing "<ctrl><alt>slash" will also change the text. Pressing "<ctrl><shift>slash" will not, contrary to the expected behavior.
I have tried the program on another system and can confirm that the problem was not limited to my desktop. I have also found out that the desired accelerator key combination can be achieved by binding the action to "<ctrl>question", the question mark being what you get when you type shift-slash. This seems inconsistent with the behavior of accelerators involving letter keys, where, for example, you can use "<ctrl>z" and "<ctrl><shift>z" for undo and redo. Therefore, I still think this should be changed.
Another instance of the same problem is that it's impossible to have "<ctrl><shift>1", "<ctrl><shift>2", ... as accelerators for several consecutive entries. Using "<ctrl><shift>exclam", ... works but is not nearly as nice for the user and probably keyboard layout dependent.
See http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-translate-keyboard-state for an explanation of what's going on here and the implied rationale (that e.g. <ctrl>plus is preferable to <ctrl><shift>equal). Note that the accel_group functions pass all keyvals through gdk_keyval_to_lower()and then apply the modifier state (which includes shift). This obviously doesn't work for symbol keys.
(In reply to comment #3) > See > http://developer.gnome.org/gdk/stable/gdk-Keyboard-Handling.html#gdk-keymap-translate-keyboard-state > for an explanation of what's going on here and the implied rationale (that e.g. > <ctrl>plus is preferable to <ctrl><shift>equal). I see, thanks. However I disagree with this rationale as, to return to my example, using accelerators 1,2,3,... for successive items is much better from the UI point of view than using !,@,#,... On a related note, I've discovered that actually specifying "<shift>" is simply ignored. I.e. in the attached example pressing "Ctrl+Shift+/" does not work but pressing "Ctrl+/" does work which IMHO can't be the desired behaviour because one key is shown in the menu but another one is actually used by accelerator.
Created attachment 219717 [details] [review] Transform <foo><shift>symbola to <foo>symbolb This gets accelerators with shifted numbers and symbols working, though the displayed accelerator will be the transformed value which isn't what Vadim is looking for. To take Phil's example, <ctrl><shift>slash will be transformed to <ctrl>question, and in Vadim's, <ctrl><shift>1 will become <ctrl>exclam. (An interesting note about <ctrl>exclam: It doesn't display anything on the menu. The accelerator still works. <ctrl>at does display; I didn't test any others.)
>(An interesting note about <ctrl>exclam: It doesn't display anything on the menu. The accelerator still works. <ctrl>at does display; I didn't test any others.) I should have qualified that with "on quartz and with integrated menus". It's not the case for X11.
(In reply to comment #5) > This gets accelerators with shifted numbers and symbols working, though the > displayed accelerator will be the transformed value which isn't what Vadim is > looking for. > > To take Phil's example, <ctrl><shift>slash will be transformed to > <ctrl>question, and in Vadim's, <ctrl><shift>1 will become <ctrl>exclam. I read the rationale and understand it, thanks. But I agree with Vadim that it doesn't always make sense from a UI point of view. For example, in the code I was trying to write that prompted me to file the bug, I was using Ctrl+/ as a shortcut for commenting out a block of code and Ctrl+? to uncomment it. It's more intuitive for the user to remember if the shortcuts are displayed in the menu as Ctrl+/ and Ctrl+Shift+/, in analogy with Ctrl+Z for Undo and Ctrl+Shift+Z for Redo ("Undo Undo"). However, I don't have a good proposal for solving this problem, since maybe the question mark isn't a shifted slash on all keyboards. Perhaps Ctrl+? could be interpreted as simply Ctrl+?, whether the question mark is shifted or not, and Ctrl+Shift+/ could be interpreted as Ctrl+whatever symbol is a shifted slash on the current keyboard layout.
I've experimented a little with a patch (not yet ready to attach, still has some unexpected behavior) that accepts e.g. <ctrl><shift>slash and converts it to whatever the keyboard thinks it is -- <ctrl>question on a US keyboard in this case. That part is pretty easy. But I'd like to make it so that it preserves what the accel-map says, and that's going to be a bit more involved. It already has the significant benefit of fixing the mapping of <ctrl><shift>slash to the very unexpected <ctrl>slash, though.
GtkAction has been deprecated
RTFB. This is about accelerators, not GtkAction.
re-titling and re-assigning to the right component, for clarity. (In reply to comment #10) > RTFB. This is about accelerators, not GtkAction. you may want to watch the tone you keep on Bugzilla, John, if you don't want to get your account suspended.
Sorry if this bug got caught in the crossfire. The thing is: it is much easier for you to reopen it if you know it is still relevant than it is for me to find it among 3000 open, often outdated bugs. Which is why I am aggressively trying to bring the bug count down.
(In reply to comment #12) > Sorry if this bug got caught in the crossfire. > > The thing is: it is much easier for you to reopen it if you know it is still > relevant than it is for me to find it among 3000 open, often outdated bugs. > Which is why I am aggressively trying to bring the bug count down. OK, I agree that this is fair game for that, since it had been inactive for 2 years. I think it'd be better to say that rather than that it's obsolete for the wrong reason.
-- 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/336.