GNOME Bugzilla – Bug 92139
Selecting "next tab" on rightmost tab should cycle to leftmost tab
Last modified: 2008-10-01 16:43:09 UTC
Hi, When on the rightmost tab in a tabbed terminal window, selecting "next tab" should cycle around to the leftmost tab. Similarly, selecting "previous tab" while in the leftmost tab should cycle around to the rightmost tab. It just makes sense.
This should be consistent with standard notebook behavior and probably the workspace-switching behavior of the WM also. Is there a HIG decision here? What does GtkNotebook do?
The spec for GtkNotebook says there should be no wraparound and it should stop with a beep... this kind of functionality was requested for all controls that manage groups of things that you can navigate around (lists, trees, notebooks, radiobutton groups etc.) by Marc Mulcahy as it's less confusing for blind users. (It's also in the Windows Accessibility Guidelines, i think). However it hasn't really been implemented for any widgets yet AFAIK and I'm guessing people who don't rely on it might find it annoying, so perhaps it's a behaviour we might want to link to the state of the global accessibility Gconf key or something... anyone else have any thoughts?
Has the debate here been resolved? Bug 98206 asked for this same behavior, and it's been marked NOTABUG. Should the same be done here?
I think we probably need to revisit this when I get around to updating the ageing GNOME keynav spec. There are several widgets that would benefit visually-impaired users by 'stopping with a beep' (e.g. lists, radio button groups, notebook tabs, text fields) rather than wrapping around or just silently stopping, and I'm not sure we have a good list of them yet.
*** Bug 112444 has been marked as a duplicate of this bug. ***
Would it perhaps be possible to leave "next tab" and "previous tab" as they are, and add a new command, which would scroll through the tabs forward, wrapping from the last back to the first? It could be mapped to Ctrl-Tab by default, which is what many people know and expect (cf. Opera, Mozilla, etc.), or even unmapped by default. Would that be an acceptable solution?
Yes, adding a new keybinding would be much better than changing the behavior of the standard notebook keybinding I think. In general we've had this issue in various places (workspace switching, etc.) and always gone with the "stop at the edge" behavior, because that just feels more solid and robust and allows "slamming to end" behavior. So I don't think the default is likely to change. I'd much much rather have a new keybinding than add a pref like "notebook motion wraps"
The other reason for stopping rather than wrapping around is accessibility; a blind user generally has no way of knowing whether focus has wrapped around or just moved on to a new item. (Their screenreader could potentially point this out, but IIRC stopping with a beep is usually preferred, provided there's a quick way to get back to the first item again e.g. pressing Home).
*** Bug 156950 has been marked as a duplicate of this bug. ***
Bug 156950 contained a patch for this enhancement: http://bugzilla.gnome.org/attachment.cgi?id=33279&action=view
Created attachment 38248 [details] [review] add gconf setting to allow wrap around in tab movement, also allow moving tabs Oops. I uploaded the patch for the two new menu items to bug #86938. I rethought this patch and imho a gconf setting to allow wrap around is better than two new menu items. This patch also includes the move tab patch from bug #106286.
This has been debated before. Some folks think that it's better to beep at the last/first tab, i.e. not to cycle around. In particular, it can be useful for accessibility, otherwise the user has no indication of when he or she is on the "first" or "last" tab. So I don't think this is actually a good idea, we should add a 'beep' at each end and not cycle IMO.
FWIW, I've recently been working with Kathy Fernandes on a review of gtk+ keynav that she's just sent to Owen, and IIRC that also recommends not wrapping, but beeping instead. (Or whatever the user has configured "beep" to mean, of course, which may be a window flash.) Unfortunately there's nothing in the HIG yet to lead us either way, but I can add something right now if it'll help :)
Is a pref like "notebook motion wraps" in the "General" tab of the profile editor in conformity with GNOME HIG ?
*** Bug 169679 has been marked as a duplicate of this bug. ***
I would really like you to reconsider. While I agree to have a default behaviour for all tabbed application windows, there is demand to add an option to disable 'hard edges' for this application. And i think it such an option should be included, because the gnome-terminal is a keyboard application, it has keyboard shortcuts to all tabs and users are likely to switch tabs more often. Especially when you got a lot of open tabs. It is really very different from a document editor or options dialog. I agree that the default option should be a 'beep', or whatever is configured. The patch was meant to add some user control and I think it is short enough too make no problems. I don't think this option is important enough to be included in the profile dialog. Imho gconf is the right place to configure this, tools like gtweakui could take care of such things in the future.
If you have so many tabs open, it's always going to be awkward to switch rapidly between them anyway, because the Alt+number technique runs out after 9 :) (And isn't terribly useful after about 5 anyway, because you have to start counting to work out which tab is which...) Having said that, I wouldn't have a great problem with wraparound being a hidden option that was turned off by default. Another idea might be to tweak the Alt+number shortcuts that most apps have adopted, and have Alt+zero mean 'last tab'. (Or use Ctrl+Alt+zero if people want Alt-zero to mean 'the tenth tab'). Then you can get to the first and last tabs just as quickly as you could by wrapping around.
*** Bug 308365 has been marked as a duplicate of this bug. ***
Created attachment 57031 [details] [review] updated patch, rediff against current gnome cvs The "move tab to" stuff has been removed from the patch. Implements a gconf setting to navigate the tabs as ring instead of a chain.
*** Bug 372891 has been marked as a duplicate of this bug. ***
I do not think having a terminal-specific pref for tab-wrapping is at a good idea. It sounds like a great candidate for a global thing: there are lots of tabbed interfaces nowadays, and despite the fact that the terminal is a little different in some ways, adding yet one more difference is bad. We could add two shortcuts, unbound by default, which go to the first and last tab. (In any case, Mario, you should listen to changes on your gconf key, so that you can react to changes)
There is a similar bug against Gtk+ IIRC, about menus, though, for removing the wrapping. The conclusion is that we need options for wrapping in menus bars, menus, and tabs. This is necessary for proper integration, since for example OS X does some of them. Found it: bug 309291.
Bug #322640 has a patch that will probably fix this issue.
Bug 309291 got closed and now HEAD gtk+ has gtksettings which cater for all this. The terminal is going to watch for those settings, as we desentitivize menu items when we hit the first/last tabs...
*** Bug 411219 has been marked as a duplicate of this bug. ***
Rejecting this patch, per comment 21 with which I agree.
*** Bug 531867 has been marked as a duplicate of this bug. ***
*** Bug 552288 has been marked as a duplicate of this bug. ***
We now use GtkNotebook, right? Shouldn't this be done in GTK+ then? That is where it belongs anyway.
This is controlled by GtkSettings:gtk-keynav-wrap-around: and GtkNotebook honors is since 2.12. See my comment #23.
However we set the next/previous tab actions insensitive when on the last/first tab.
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.