GNOME Bugzilla – Bug 643831
keyboard: doesn't handle AboveTab
Last modified: 2018-05-02 15:02:52 UTC
mutter invented this extra-special pseudo-keysym for binding 'Switch windows of an application' to Alt+AboveTab. The keybinding works fine, but it appears as 'Disabled' in the list of shortcuts, which is unfortunate.
The biggest challenge here will be to allow the user to get back to AboveTab by entering the backtick.
*** Bug 651597 has been marked as a duplicate of this bug. ***
This bug still affects mutter and GNOME 3.2. The current behavior is obviously wrong (because the key binding is not disabled) and I suggest that whatever solution was intended with this extra-special pseudo-keysym cannot do more good than the harm and confusion that is caused by the incompleteness of its implementation. It would be best to back out the use of AboveTab until its implementation is completed by informing users that it exists.
Gordon, what are you talking about? Talking in riddles and in possible reference to some other discussions that we weren't a part of isn't helping.
I apologize for any confusion. I was under the impression that because this bug was filed on the keyboard component of the control center, that the person who opened it was clear on the matter. In theNavigation section of the Keyboard control's Shortcuts tab, the option "Switch windows of an application" reads "Disabled", though Alt+` will switch windows of an application. Mattias seems to have suggested that this is because mutter has invented some pseudo key that can't be displayed in the control center. If that is the case, I suggest that mutter simply use the '`' character until such time as the implementation of AboveTab is completed by finishing support for it in the Keyboard section of control center.
You are missing the point of the pseudo keysym. It expresses something entirely different than '`' . 'AboveTab' means 'the key that is positioned above the Tab key in the keyboard geometry' - inventing this was necessary precisely because '`' is not equivalent to that.
Now that both gnome-settings-daemon and gnome-control-center use GTK+ itself to parse those strings, we should move the code from mutter to GTK+ itself, and g-c-c and g-s-d would get the support for free.
Most of the code lives in mutter:src/core/above-tab-keycode.c
Either we can hide that inside the X11 backend, in the lookup_keyval() implementation, by looking up the keysym back from the keycode (using the mutter code), or we would need to add a new vfunc to the display objects.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Created attachment 368392 [details] above tab example Still happens with GTK+ 3.22 and GNOME 3.26.
-- 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/353.