GNOME Bugzilla – Bug 94256
Tab switching on tab closure is unintuitive
Last modified: 2004-12-22 21:47:04 UTC
When a tab is closed, the tab that is immediately next to it is activated. (Usually the one to the left, but if there is no tab, the one to the right.) This is only confusing if the activated tab is not the one that was most recently used. To repeat, have two tabs open, the leftmost one active, open a link in new tab and close the new tab. Now the second tab is suddenly active.
*** Bug 95467 has been marked as a duplicate of this bug. ***
Comment by Lee Willis on a related bug: Tommi seems to be suggesting an algorithm based on "previous" tab, ie we go to the previously active tab. For my browsing habits Tommi's suggestion wouldn't be an improvement over the current implementation (Since in my case they normally work out about the same!). I think an explanation of browsing habit may be in order. I start off with one tab (Think of it as a document containing several links, e.g. a news site, or a tasklist). I go down the list an open the links of interest into new tabs, leaving the list still open. I then move to the first tab I opened. When I've finished on that tab I close it and *WANT* to move on to the next tab to continue working through the items I opened, but galeon takes me back to the list (At this point the current logic and tko's will have had the exact same effect). So if I had to choose I'd say either implement my logic, or leave it as it is (I don't think the development of a "Move to previous" tab would be worth the effort) From experience with my gf interfaces which are obviously predicatable are easier to understand. Moving to previous tab (Current implementation), or moving to next tab (My proposed implementation) are "obvious" algorithms. Moving to a "random" tab in the last is less obvious until you realise it's the last tab you worked with (Especially if you've spent some time away from the tab). My 2p.
I'm not sure if there can be one solution that fits all. This will propably need a different algorithm based on the combination of the following preferences: - Jump to new tabs automatically - Insert tabs after current tab Though, if you *sigh* remove the hidden one... :-/
I think we should just choose the best behavior. The best = the more intuitive.
Most of the time I open one new tab, read it and close it, then open another one. In this mode it makes sense to return back to the most recently active tab. Currently this gets broken if there are tabs open between the new tab and the most recently used. If I didn't disable the 'New tabs after the current one' option, the above would work. But the reason why I *do* disable it is that it makes opening multiple tabs appear in the notebook in reverse order. And that just isn't sane, I read the links I open in the same order I open them. In this mode I open the multiple tabs, close the current one and expect to be seeing the *first* new tab I opened, not the last one. I think that only the 'Jump to new tabs automatically' needs to be configurable, with a modifier to change the default. Next tab should be determined from the user's browsing mode. (Above is based on my behavior, I'd like to think it's not unique :) In summary: - tabs should be inserted after the current tab, but so that their order in the notebook matches the order of opening - if a tab wasn't automatically jumped in to when opened, switch to the tab on the right when closing - if a tab was automatically jumped in to, switch to the tab on the left Does this make any sense? At the moment, assume that the order of tabs is fixed, that they can't be moved around manually once opened. That should help to focus on the basic model. Worry about the user messing up the order later.
>- tabs should be inserted after the current tab, but so that their >order in the notebook matches the order of opening Sounds like a very good solution to me. >- if a tab wasn't automatically jumped in to when opened, switch to >the tab on the right when closing >- if a tab was automatically jumped in to, switch to the tab on the >left I dont get exactly the rationale behind this, could you elaborate ?. I have this impression it could be potentially confusing because File->New Tab will jump to and open in new tab from context menu will not even with default setup. We are getting near to a good solution though :)
If we remove the pref for choosing whether to jump to new tabs automatically, and the standard behaviour is that we don't then I agree with Tommi. (That's how my galeon 1 was set up anyway!) If we've kept that option [I don't have galeon2 to hand - sorry!] and follow Tommi's suggestion then we have a problem since the tab closing algorithm will be affected by an apparently unrelated pref which strikes me as bad from a useability point of view.
The pref is still there and default is not to jump.
I think we have a problem then. What's intuitive closure behaviour for the "default" setting isn't intuitive for the behaviour you get by changing that pref. That leaves us with either: 1. Living with unhelpful behaviour if people change the pref (ie our closure algorithm is optimized for the default) 2. We change the closure algorithm if they change the pref (More work, and potentially confusing for the user - "Hey, Why's it taken be to that tab. It normally moves me to the next tab along") 3. We introduce a tab closure pref. 4. We remove the tab jumping to pref. Out of all of those my order of preference would be: 2 - It might not be an issue since it should be intuitive for the behaviour they've chosen 1 - Obvious, but not very useable 3 - We don't like adding confusing prefs [And this won't be easy to explain!] 4 - There are simply too many different browsing "habits" for us to remove this!
If we can agree on the tab order, it also means you can get rid of that visible pref :) I tried to explain that there are propably two behavioral models for browsing. In the other you basically open only one new tab, read the page, then close the tab, open another one, read, close, etc. Here 'jump to new tabs automatically' is very much expected. Closing the new tab should return to the previous tab (on the left.) In the other you open multiple new tabs "to be read shortly afterwards." You want to open all interesting links from the current page, then close that tab and continue reading links. Here 'jump to new tabs automatically' is not suitable. Closing the tab should advance to the next tab (to the right.) For File/New Tab, jumping to the new tab automatically is basically mandatory, it would otherwise be just confusing. Context menu and middle-clicking need to act similarly to each other, but I'm uncertain whether File/New Tab and the context menu should also. I'm inclined slightly towards that they should. If they should all act similar, there's no need for the other pref. If you think there's a difference, you need the pref. Either way, you still need the modifier if you plan to support different browsing behaviors.
They are very different behavior and it's not a big deal if also the ordering is different between them IHMO. Not good but I think we can ignore it. Tko, what about File->New Tab case ? IHMO we should follow the pref even with that, prolly less confusing.
As I've said earlier, my biggest annoyance was that the tabs were in reverse order. You need to switch to the new tab (File/New Tab) anyway to get anything useful out of it. It just doesn't make sense to not do it automatically.
Hmmm damn I didnt mean that about New Tab. Anyway I think I have clear what your proposal is and I agree with it. I'll see if I can do a patch for it in the weekend if no one does before.
So, have we agreed on: 1 We leave the current default as no jumping to new tabs automatically 2 We keep the pref to enable this if users want 3 The closure algorithm is move to tab to the right regardless of the above pref. 4 Tabs always open next to the current tab, but keeping the order they were opened in (See my 1 2 3 4 example above) 5 New tabs created by explicit menu/toolbar button actions are always jumped to regardless of the pref in 2. That seems OK to me.
Not sure about the closure alghoritm. I have a terrible headache and I cant really get things well this morning :( Let's see if tko confirm he is ok with ever to the right algo.
lwillis: I'm sorry, but just how exactly did you get in such a conclusion?! > 1 We leave the current default as no jumping to new tabs automatically Definitely not, I'm afraid. No surprises to new users, please. Every other application I can think of jumps to new tabs automatically. > 3 The closure algorithm is move to tab to the right regardless of the above pref. Sorry, won't work if 'jump to new tabs' is enabled, the tab after the closure is to the left. > 5 New tabs created by explicit menu/toolbar button actions are always jumped to regardless of the pref in 2. If you did 1. as well, you'd get one seriously inconsistent default behavior. New tabs are sometimes jumped to automatically. If you have to choose between two prefs, pick the one that provides more consistent behavior as the default.
I'm having doubts about my original statement about File/New Tab behavior. 'Jump in to new tabs automatically' must be enabled by default, that's how everything else works, and when compared to New Window provides more consistent default behavior. But when the user chooses to disable the 'Jump in to new tabs automatically' then we must assume he really means that -> if disabled, File/New Tab must open a new tab in the background as well. We must not start second-guessing user's preferences. I don't know what I was thinking at first... :-/
I'd prefer to leave 1 and 5 out of this discussion. We can address it in another bug. About 3. Lee are you fine with the behavior proposed by tko ?
Marco > I'd prefer to leave 1 and 5 out of this discussion. > We can address it in another bug. In which case we need to resolve *that* bug before we decided what the "right" solution is for this one! > Lee are you fine with the behavior proposed by tko ? It makes sense if (And *only* if) "Jump to new tabs automatically" is enabled. Right now it isn't (In a default install) and the algorithm seems wrong. Decide what you want to do for "jumping to tabs" first, then we can make this decision properly. Until then we might as well just stick with current behaviour. Tommi: > lwillis: I'm sorry, but just how exactly did you get in such a conclusion?! Based on Marco's comments - but I wasn't sure, that's why I asked :) > > 1 We leave the current default as no jumping to new tabs > > automatically > > Definitely not, I'm afraid. No surprises to new users, please. I'd be more concerned about "No suprises to existing users" - ie what's the default in galeon 1? > Every other application I can think of jumps to new tabs > automatically. Hmm, I can only think of 1 (gedit) and that's not a good comparison (IMHO). In gedit you're switching what you're doing *explicitly* by opening a new document. The "File->New tab" entry in galeon has the same *explicit* context as gedit so it should "Jump to" regardless of settings, clicking to open a link isn't the same(For me). I think we've already had this discussion when we did galeon 1 and decided that "File->Open" should ignore the preference and no-one really complained (As far as I can remember) - perhaps that's the most intuitive behaviour? Tommi: > If you did 1. as well, you'd get one seriously inconsistent default > behavior. New tabs are sometimes jumped to automatically. Not really - think in terms of what the *real* actions are. In the case of *explicitly* asking for a new tab you get a new tab jumped to for you. In the case of following a link, the fact a new tab has to be opened is implicit (It's a technical requirement - not something the user has *explicitly* asked for) so it doesn't have to follow the same rules to be consistent, they're two different actions. Although it may seem it I don't have any particularly strong feelings on it other than galeon (1&2) defaults seemed right for me on this case. As Marco said it is separate to this bug, but needs to be decided on before we can do the right thing for this bug. My suspicion is that we keep the option (It's evident you like it - and my guess is that many others do too), and that we simply have to alter the tab closing logic based on the value of that pref. That's my thoughts - I'll not prolong the bug any more :) Over to you guys ..
Existing users already have their configuration set up, the change shouldn't affect them at all. Hmm.. mozilla jumps to the new tab automatically, phoenix doesn't. Though phoenix does have tabbed browsing enabled by default. xirssi (IRC client) jumps to new tab by default when you /join a channel, that is sufficiently equal to your implicit new tab example. Oh, and be aware that I consider tabs as a replacement for windows, less cluttering the desktop, nothing more. That's why I expect the tab should be automatically activated, just like new windows are. Umm, am I commenting on the wrong bug again :-?
Latest news: galeon1 had it right, let's port the galeon Smart Tab Selection Technology (tm) to galeon2. In short (hope I didn't misinterpret the code): - if a tab was automatically jumped in to (according to the pref, or overridden with the modifier key,) on closure return to the most recently used tab. - if a tab was not automatically jumped in to, on closure jump to the next one on the right.
implemented g1 smart selection. And fixed the reversed order problem. There may be bugs, please report them. Lee I guess this behavior is good for you too, if it's not please talk :)
Created attachment 11708 [details] [review] fix src/galeon-nautilus-view.c:512: too few arguments to function `galeon_window_add_tab'
Did you even try running galeon after patching? :) 1. tabs are still inserted in reverse order after current tab 2. closing tabs that were never activated makes some other tab active Have one tab open, open three more, the original is always active. Close the rightmost tab, which was never activated. The second tab is now activated. This Smart Tab Tech(tm) is relevant only when the active tab is closed.
Uhm 2 should be easy to fix. Dunno about 1 ... but I did the necessary arch changes so it should be just a bug. I cant work on this now because I need to recompile mozilla. If you can convince someone to check in your path would be good ;)
For what it's worth current CVS works perfectly for me right now ...
Let's try to close it again and see if tko has some more nitpicks ;)
Well... Since you asked for it... :) I'm not sure if it's good to have the smart tab closure tech(tm) in the gul-notebook. I think it belongs to galeon-window instead. No strong feelings though.