GNOME Bugzilla – Bug 123994
Need to document: Can't assign ctrl-tab or ctrl-shift-tab in keybindings
Last modified: 2015-10-16 06:58:01 UTC
Whenever I try and assign ctrl-tab or ctrl-shift-tab to any of the keybindings (tested: File/New Profile, View/Full screen), neither one takes. I click on where it says "Disabled", it prompts for the new accelerator, and when I hit ctrl-tab or ctrl-shift-tab it goes right back to "Disabled". In fact, doing this on an already set keybinding will unbind it to "Disabled".
There are a couple of keys which are not candidates to be keyboard accelerators, independently of the modifiers. Tab is one of those keys, as it (with various combinations of modifiers) are reserved by gtk for its own use and the window manager. Note that validity is decided by calling gtk_accelerator_valid, but the list of valid accelerator keys seems to be only in the source (which you can find at http://cvs.gnome.org/lxr/source/gtk+/gtk/gtkaccelgroup.c#790, in case you feel like it) This is, then, not a bug. I'm not closing this, because this should be mentioned in the docs (the docs do not mention, either, the fact that keyboard shortcuts can be edited...) and hence adding the doc keywords.
Moving to the docs component, which we now have, and updating the summary.
Moving to default Docs assignee. Sorry for the spam
Fixed.
The link http://cvs.gnome.org/lxr/source/gtk+/gtk/gtkaccelgroup.c#790 does not work, i get 404 Not Found
I think that is a serious limitiation to not be able to use Ctrl-Tab as a keyboard shortcut in Gnome applications. Elsewhere, it is a convention to use Ctrl-Tab to switch between tabs/subwindows within an application. You use this in e.g. Mozilla Firefox, and I successfully configured Eclipse for this behaviour. Since you use Alt-Tab to switch between applications, it's quite convenient to be able to use Ctrl-Tab to swtich tab/subwindow within an application.
As I understand it, this bug report was closed because GTK doesn't support this functionality. Could you consider pushing it upstream to GTK? Not being able to use Ctrl-Tab is certainly a widely desired feature. If you don't want to try to remove the limitation in GTK that makes it impossible to support Ctrl-Tab, then at least mark it WONTFIX rather than FIXED :-(. Could you reopen this and have another look at it please?
Tab, Shift-Tab, Ctrl-Tab and Shift-Control-Tab are reserved in all gtk+ applications, for focus movement.
>Tab, Shift-Tab, Ctrl-Tab and Shift-Control-Tab are reserved in all gtk+ >applications, for focus movement. gnome-terminal traps the Tab keypress for its own use (the Tab character is passed on to the program running in the terminal) so I guess it could trap Ctrl-Tab as well? If not, can the bug be pushed upstairs to gtk+? (If you agree that switching tabs with Ctrl-Tab a la Firefox, etc. is a desirable feature.)
*** Bug 551310 has been marked as a duplicate of this bug. ***
pidgin <http://pidgin.im> is an example of a GTK+ application that lets me use ctrl+tab to switch between tabs. I have included an excerpt from their source [pidgin/gtkconv.c - Copyright GPL] that shows how they are trapping it - though I do not know whether a similar technique is usable by gnome-terminal. conv_keypress_common(PidginConversation *gtkconv, GdkEventKey *event) { /* ... */ if (event->state & GDK_CONTROL_MASK) { switch (event->keyval) { /* ... */ case GDK_Tab: case GDK_KP_Tab: case GDK_ISO_Left_Tab: if (event->state & GDK_SHIFT_MASK) { move_to_next_unread_tab(gtkconv, FALSE); } else { move_to_next_unread_tab(gtkconv, TRUE); } return TRUE; break;
*** Bug 585674 has been marked as a duplicate of this bug. ***
The stubborn Gnome Terminal developers has decided that this is not a desirable feature. For those of us who thinks otherwise, it's possible to configure the old trustworthy xterm to act quite like Gnome Terminal with Ctrl-Tab tab switching: http://www.staldal.nu/tech/2009/01/10/how-to-use-ctrl-tab-in-gnu-screen/
*** Bug 602657 has been marked as a duplicate of this bug. ***
I just stumbled across this, I posted a bug about it and apparently it is a duplicate. There are so many people requesting it and so many duplicate bugs. I understand the GTK requirements but if pidgin is allowed to change it, why not gnome-terminal? This is a shortcut used in a variety of applications which use tabs. In fact, I think any application which uses tabs uses also this shortcut. Thanks for your time.
(In reply to comment #13) > The stubborn Gnome Terminal developers has decided that this is not a desirable > feature. This language is not appropriate on this forum. Please see: http://live.gnome.org/CodeOfConduct
(In reply to comment #15) > if pidgin is allowed to change it, why not gnome-terminal? Pidgin is not a Gnome application. If they choose to be inconsistent with the whole of Gnome, that's their choice — a bad one. > In fact, I think any application which uses tabs uses also this shortcut. No Gnome MDI application does this. In fact, this has been explicitly rejected every time it's come up; see e.g. epiphany bug 122467 (+ some non-marked dups), gnome-terminal in bug 123994, gedit bug 314646, empathy bug 586831, nautilus bug 597096.
Well, if it keeps coming up and users are asking for it, maybe its the GNOME/GTK policy that is wrong?
I (In reply to comment #18) > Well, if it keeps coming up and users are asking for it, maybe its the > GNOME/GTK policy that is wrong? I wrote to desktop-devel-list about this: http://mail.gnome.org/archives/desktop-devel-list/2009-November/msg00220.html
Thanks a lot, I really appreciate it.
*** Bug 625843 has been marked as a duplicate of this bug. ***
*** Bug 644587 has been marked as a duplicate of this bug. ***
> Pidgin is not a Gnome application. > If they choose to be inconsistent with the > whole of Gnome, that's their choice — a bad one. It is hardly an inconsistency when you add additional feature (however it is hardly a feature to work properly). Anyway, what is the reason of forbidding ctrl+tab as shortcut? First we heard it is because of Gtk (not true), then it is because of Gnome -- assuming Gnome is the real reason, it is just a guideline or it is blocked directly in code?
The email chain here says the point of CTRL-Tab and CTRL-Shift-Tab is for applications to change focus between widgets/fields... but gnome-terminal DOESN'T have widgets in this sense... it's just a block of text, right? One widget. If each tab doesn't just swap text buffers to that same text widget (I don't know the source), but rather each tab is a separate text widget then shouldn't CTRL-Tab then work by default to change tabs? But it doesn't. :( Can someone propose a patch based on the pidgin code?
Whoops, forget the link (and can't find how to edit): https://mail.gnome.org/archives/desktop-devel-list/2009-November/msg00220.html
I wanted to have Previous Tab, Next Tab & Close hotkeys match Firefox & Sublime since I've been using Firefox 10 + years more than I've been using Gnome. I wasn't able to get Ctrl + Shift + Tab thanks to the code overlords guarding the holy <Tab> from being a accelerator... Instead I was able to get Ctrl + ~ and Ctrl + Shift + ~ hotkeys which are really close. Now I can finally switch through tabs without putting two hands on the keyboard. -------------------------------------------------------------------------------- # Enable Changing Accelerators in dcon-editor here: org > gnome > desktop > interface > can-change-accels # Open ~/.config/nautilus/accels # Find: ; (gtk_accel_path "<Actions>/ShellActions/Close" "<Primary>w") # Replace With (gtk_accel_path "<Actions>/ShellActions/Close" "<Primary>F4") # Find ; (gtk_accel_path "<Actions>/ShellActions/TabsMoveLeft" "<Primary><Shift>Page_Up") # Replace With (gtk_accel_path "<Actions>/ShellActions/TabsMoveLeft" "<Primary>asciitilde") # Find ; (gtk_accel_path "<Actions>/ShellActions/TabsMoveRight" "<Primary><Shift>Page_Down") # Replace With (gtk_accel_path "<Actions>/ShellActions/TabsMoveRight" "<Primary>grave")
Since this "bug" has been retitled to only refer to documentation of this limitation, other bug reports complaining about the limitation are not duplicates. There should be a separate bug, possibly in WONTFIX status, for the dupes to point to. PS: "me too" on this being a stupid limitation. Can someone point me to what ctrl+tab actually does in any gnome applications? I'm used to using just plain tab to move between interface widgets.