GNOME Bugzilla – Bug 330676
Tabs 'disappear' in core Gnome applications because they scroll instead of resizing
Last modified: 2018-05-02 14:16:43 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/30749 When opening more than a few tabs in Gnome applications like Gedit, Epiphany etc, earlier tabs suddenly disappear with no warning and almost without trace. All that is seen are two tiny arrows beside the tabs which allows the user to scroll the tab list to reach the other tabs. When this happens the first few times it's a very confusing, and also scary and upsetting experience - "where did my important tab go?" "Did I save?" "Please, please, please be in my history". After finding out what actually happens, and at least understanding it, it is just incredibly annoying and unusable. The huge advantages that tabs offer are totally lost: instant overview and one-click access. Without those, might as well use separate windows like Internet Explorer or Notepad, although they only get as inaccessible after their windows have grouped on the task list. Almost all other tabbed systems shrink their tabs when needing to, and it works great for them. A few expand into multiple rows instead. I thought long and hard before filing this bug, because this is a sensitive question apparently - common opinion is that this is a 50/50-issue, some love this, others hate it. Personally I've mostly seen hate, and I deeply, strongly feel that this must be addressed one way or the other, so here goes. Summary on current behaviour: * It is scary, surprising and confusing * It takes away the instant overview of tabs * It takes away the instant access of tabs I suggest that: * GtkNotebook gets another mode of operation, where tabs shrink instead of disappear when space becomes scarce. * If use open an incredible amount of tabs, it's ok to disappear them though, we can't do magic and there's just so many pixels. * Old mode of operation is also kept, and a global preference for the whole Gnome desktop switches all GtkNotebooks to either behaviour for all using applications. * Default is changed to Resize, because: - That is what any tab savvy user is used to - That doesn't scare by making things disappear suddenly - It's better usability with instant overview and access * Nice to have: multiple row tabs as third option. So, you heard me right. I propose to add extra options to Gnome. =) I think it's warranted though. If it's such a 50/50 issue, there can hardly be a good default. The current behaviour is scary and unintiuitive, but have a loyal following. Those should be able to retain their experience, just like there is spatial and non-spatial Nautilus. For a more humorous rant on this frustration, I wrote this post a little while back: http://ubuntuforums.org/showthread.php?t=124068 =) It would be nice if this was an setting that the user could set.
It is certainly possible for apps to implement the "tab shrinking" themselves, see gnome-terminal. See bug 110540 for a long discussion about multiple rows of tabs.
I have several reasons for wanting to make this a central change: * Everyone gets it the way they want it instantly in all apps that use GtkNotebook - no matter your preference. * That also means that even more (new) apps could safely use it and users would be happy. * One fix in one place, one implementation - much less effort than fixing lots of apps and easier to keep high quality and bugfree. DRY. * In mailing list discussions, developers throw back the request with the argument that it is a Gtk issue and thus should be fixed in Gtk: - http://mail.gnome.org/archives/epiphany-list/2005-November/msg00025.html - http://sourceforge.net/mailarchive/message.php?msg_id=795361 - (that's just quick google, I've seen it more times) I see that that thread didn't really reach any conclusion either, nor have any other forum or mailing list thread on the subject that I have seen at least. And it's not an uncommon topic, especially in distro forums all over the place, since so many feel strongly about it in either direction. This could solve it once and for all, because apparently, as it is today, a lot of people are unhappy with the apps that exist, be it epiphany or gnome-terminal and would rather have it their way all the way? The way I see it, it may be a bitter pill, but it's also "take the medicine, and the illness Will be cured", instead of curing a few symptoms here and there.
I don't agree with the suggestion to change to Resize by default and leave the current behaviour as a preference, because that will leave the large majority of users that will never see a preference window with tab handling that's just as broken as the current one, just in totally new ways.
> tab handling that's just as broken as the current one, just in totally new ways. That is tab handling that isn't broken to the many millions of Firefox users or for all the users of just about any tabbed browser, text editor, IDE or other application. There may be philosophical arguments that it is broken, but it is working well for all of these people today, and have for many years. About the only thing that gets more effective with fixed tabs is closing many quickly, which I really wonder why it is more important than effectively using them (overview, access). Why is closing a priority? Mind you, anyone who uses few enough tabs for them not to disappear will also use few enough that they won't resize. A non-problem for those users.
I am in favor of the resize option. If the goal of the current behavior is to be easy to use then I think the current implementation fails. It is undiscoverable and scary to new users. There should be enough reason to change the behavior given that users find the current bechavior scary. Im pretty sure scary is advised against in the HIG. If we aim for ease of use then we should go with resizeable tabs. Familiarity and ease of use are two sides of the same coin in this case; look at the behavior of firefox and gnome-panel. They resize! I dont think there is sufficient reason to behave differently than those applications. One advantage of fixed tabs is that they are easy to close. To maintain that function we could close tabs on middle click like firefox. As for two rows of tabs, I think that could come after. Getting this fixed first would be a stellar improvement!
Nice discussion here. People should realize though, that nothing is going to change unless someone starts actually working on this...
> People should realize though, that nothing is going to change unless > someone starts actually working on this... That is always true, isn't it? =) For us who can't do it ourselves (and don't have the funds to pay for it being done either), then all we can do is report and discuss the issue and hope that it will get done by someone else. That is no sure way to get it fixed, but at least I'm trying to do my part with reporting that there *is* a problem and convincing whoever can fix it that it is a real problem. I have no illusions that anyone is obliged to fix *my* problems, but I think this is something that would help make a better system overall, so I come here. I hope that is a welcome contribution to development as well. (Yep, I've tried fixing it myself with the idea that I'd at the very least have a locally patched GtkNotebook that I could use, but I couldn't do it. My C skills aren't good enough, or the interactions are too complex for me - in short, I got lost repeatedly and finally gave up. I got some help on IRC, but was obvious that I didn't know what I was doing anyways. =))
(In reply to comment #4) > > tab handling that's just as broken as the current one, just in totally new ways. > > That is tab handling that isn't broken to the many millions of Firefox users or > for all the users of just about any tabbed browser, text editor, IDE or other > application. There may be philosophical arguments that it is broken, but it is > working well for all of these people today, and have for many years. I can at least testify that the firefox way doesn't work for me. Open 40 tabs in in window, and try to reach the last ones.
I think it would be less confusing if the tabs wouldn't scale to fit the available space exactly. Partially displayed tabs at the sides would show the user that "there is more". Also, the arrows at the sides shouldn't change the active tab, they should scroll the tab area (e.g. in Epiphany changing the active tab marks all the activated tabs as "read", even if the only thing you want is find one certain tab).
For who is wondering about what the "marking tabs read" effect described in comment #9 is about, you get bold tab labels when you activate the "Tab states" epiphany extension and the page under that tab has not been viewed yet.
*** Bug 345912 has been marked as a duplicate of this bug. ***
*** Bug 347836 has been marked as a duplicate of this bug. ***
About this problem in epiphany : after trying epiphany for a week, I blogged about this "experiment"[0], and Frederic Peters kindly mentionned a set of unofficial extensions solving this[1]. [0] http://www.lucas-nussbaum.net/blog/?p=200 [1] http://www.sstuhr.dk/epiphany-extensions/
>I can at least testify that the firefox way doesn't work for me. Open 40 tabs >in in window, and try to reach the last ones. I think we should stick to more common use cases and these Id say are at <=20tabs which are perfectly handeled by the ff2.0 way: first the tabs are shrunk and then the close button is only displayed on the active tab. furthermore there is a drop down list of all windows at the right. And if you open in the current way, how often you have to click the arrow to get the least one? If you are not at the ends where the arrows are isnensitive, you cant tell how long to go. Theres a reason why the panel uses scale-to-fit as well...
still valid.
Adding "usability" keyword because, well, this is "a usability/user interface change where the correct behavior is not necessarily obvious and input from the usability team is desired." :)
Retitling for searchability (and clarity).
*** Bug 688948 has been marked as a duplicate of this bug. ***
*** Bug 665537 has been marked as a duplicate of this bug. ***
(In reply to Vincent Untz from comment #8) > (In reply to comment #4) > > > tab handling that's just as broken as the current one, just in totally new ways. > > > > That is tab handling that isn't broken to the many millions of Firefox users or > > for all the users of just about any tabbed browser, text editor, IDE or other > > application. There may be philosophical arguments that it is broken, but it is > > working well for all of these people today, and have for many years. > > I can at least testify that the firefox way doesn't work for me. Open 40 > tabs in in window, and try to reach the last ones. Just double click on ">" in firefox, to reach the last tab and double click on "<" to reach the first tab.
Please give some love to tabs, this is one component which deserve gnome love. Please see: https://people.gnome.org/~jimmac/adwaita/tabs-0001.webm also: https://people.gnome.org/~jimmac/adwaita/tabs-0003.webm Four gnome base apps need the tabs the most: 1. gedit 2. gnome-terminal 3. epiphany 4. nautilus At least gnome-terminal has a "Tabs" menu (which eventually will be gone with the menu), but gedit, epiphany, and nautilus simply lack basic functionality for more than 3 tabs! gnome is depending on firefox for web browser, so epiphany is thrown back, so, when nobody is using epiphany, who would be bothered about tab management? I want to use epiphany for my web browsing, but tab management makes it impossible. gedit, at least has "fixed tab size" unlike nautilus or gnome-terminal who only show "..." when many tabs are opened. Please consider improving tab interface and management. Thanks.
We are planning to get rid of tabs in Epiphany, because they suck. They suck in gedit too. If you use a lot of tabs in Terminal or Nautilus, I have no doubt they suck there. (Look at Builder for a good example of how to handle context switching without tabs.) But Jakub's first mockup is very interesting. If that was implemented, we might keep tabs.
(In reply to Michael Catanzaro from comment #22) > We are planning to get rid of tabs in Epiphany, because they suck. They suck > in gedit too. If you use a lot of tabs in Terminal or Nautilus, I have no > doubt they suck there. (Look at Builder for a good example of how to handle > context switching without tabs.) > > But Jakub's first mockup is very interesting. If that was implemented, we > might keep tabs. Which mockup from Jakub are you referring to? Anyway, there has been a lot of thinking about replacing tabs in Epiphany in the past, but nobody has actually done it. There was more on this on the Gnome Wiki, but this is what I can find back right now: https://wiki.gnome.org/Apps/Web/Development/FeatureDesign/EpiphanyRedux/FirstAttempt I hope the current thinking on replacing tabs can be added to that page or in some design document so that others can provide feedback.
Hi, GTK people :) Check the mockups in Bug 755388 for more tabs ideas.
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.
I can confirm this issue is still present in 3.22.
-- 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/257.