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 92139 - Selecting "next tab" on rightmost tab should cycle to leftmost tab
Selecting "next tab" on rightmost tab should cycle to leftmost tab
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
2.2.x
Other Linux
: Normal enhancement
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 112444 156950 169679 308365 372891 411219 531867 552288 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-08-30 18:19 UTC by Christian Marillat
Modified: 2008-10-01 16:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add gconf setting to allow wrap around in tab movement, also allow moving tabs (10.75 KB, patch)
2005-03-04 15:12 UTC, Mario Manno
none Details | Review
updated patch, rediff against current gnome cvs (4.84 KB, patch)
2006-01-09 14:15 UTC, Mario Manno
rejected Details | Review

Description Christian Marillat 2002-08-30 18:19:19 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.
Comment 1 Havoc Pennington 2002-09-22 22:14:14 UTC
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?
Comment 2 Calum Benson 2002-09-23 11:30:16 UTC
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?
Comment 3 Heath Harrelson 2002-11-12 19:35:05 UTC
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?
Comment 4 Calum Benson 2002-11-21 14:21:05 UTC
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.
Comment 5 Olav Vitters 2003-06-21 23:35:29 UTC
*** Bug 112444 has been marked as a duplicate of this bug. ***
Comment 6 Anatoly Vorobey 2003-08-10 18:52:00 UTC
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?
Comment 7 Havoc Pennington 2003-08-10 19:18:11 UTC
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"
Comment 8 Calum Benson 2003-09-08 12:43:56 UTC
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).
Comment 9 Olav Vitters 2005-01-03 22:19:15 UTC
*** Bug 156950 has been marked as a duplicate of this bug. ***
Comment 10 Olav Vitters 2005-01-03 22:20:06 UTC
Bug 156950 contained a patch for this enhancement:
http://bugzilla.gnome.org/attachment.cgi?id=33279&action=view
Comment 11 Mario Manno 2005-03-04 15:12:41 UTC
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.
Comment 12 bill.haneman 2005-03-04 15:23:44 UTC
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.
Comment 13 Calum Benson 2005-03-04 15:48:56 UTC
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 :)
Comment 14 Julien Gilli 2005-03-09 14:32:37 UTC
Is a pref like "notebook motion wraps" in the "General" tab of the profile
editor in conformity with GNOME HIG ?
Comment 15 Olav Vitters 2005-03-09 17:08:49 UTC
*** Bug 169679 has been marked as a duplicate of this bug. ***
Comment 16 Mario Manno 2005-03-09 19:56:42 UTC
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.
Comment 17 Calum Benson 2005-03-24 17:26:26 UTC
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.
Comment 18 Olav Vitters 2005-07-01 19:17:45 UTC
*** Bug 308365 has been marked as a duplicate of this bug. ***
Comment 19 Mario Manno 2006-01-09 14:15:46 UTC
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.
Comment 20 Mariano Suárez-Alvarez 2006-11-15 17:07:07 UTC
*** Bug 372891 has been marked as a duplicate of this bug. ***
Comment 21 Mariano Suárez-Alvarez 2006-11-15 17:29:16 UTC
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)
Comment 22 Behdad Esfahbod 2006-11-15 18:44:08 UTC
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.
Comment 23 Michael Natterer 2006-11-15 19:38:05 UTC
Bug #322640 has a patch that will probably fix this issue.
Comment 24 Mariano Suárez-Alvarez 2006-11-21 16:44:00 UTC
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...

Comment 25 Christian Persch 2008-03-25 22:27:02 UTC
*** Bug 411219 has been marked as a duplicate of this bug. ***
Comment 26 Christian Persch 2008-05-31 20:24:36 UTC
Rejecting this patch, per comment 21 with which I agree.
Comment 27 Christian Persch 2008-06-15 21:03:58 UTC
*** Bug 531867 has been marked as a duplicate of this bug. ***
Comment 28 Christian Persch 2008-09-15 11:26:02 UTC
*** Bug 552288 has been marked as a duplicate of this bug. ***
Comment 29 Behdad Esfahbod 2008-09-15 17:04:12 UTC
We now use GtkNotebook, right?  Shouldn't this be done in GTK+ then?  That is where it belongs anyway.
Comment 30 Michael Natterer 2008-09-15 17:37:35 UTC
This is controlled by GtkSettings:gtk-keynav-wrap-around: and GtkNotebook
honors is since 2.12. See my comment #23.
Comment 31 Christian Persch 2008-09-15 19:38:59 UTC
However we set the next/previous tab actions insensitive when on the last/first tab.
Comment 32 Christian Persch 2008-10-01 16:39:17 UTC
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.