Please study




http://digilander.libero.
it/chiediloapippo/Engineering/iarchitect/tabs.htm




and reconsider.

I don't think that page is appropriate.  Yes, having lots of tabs is
bad, but if there already are lots of tabs, using multiple rows is
better than using arrows like gtk does now.  In fact that page
mentions the use of arrows, and seems to imply they're worse than a
simple multiple-row tabs design (like I feel).

I am thinking about this in the context of a user having opened 20 or
30 documents at once, which is difficult to deal with, but we should
do our best.  I don't know of any way that'd do it better.

My recommendation is to keep it as simple as possible.  No resizing or
reordering of the tabs, except to rotate all the rows so that the
active row is on the bottom.  The relative positions of the rows and
tabs would all remain the same.

What about using a drop down menu instead of the arrows?

That's a bit better than arrows, since it only requires 2 clicks, as
compared to 5 or 10, but still not as good as using multiple rows.

Another point is that irc clients such as xchat will change the color
of the tab when the channel has shown activity.  This allows you to
see at a glance which channels need to be looked at.  Arrows and a
drop down menu wouldn't allow that.

Actually, for the drop-down menu to work seamlessly, it would have to
reparent the tab-widget's label (which is a GtkWidget*) into the
GtkMenuItem (which would work fine).

I think the drop-down menu is the best idea: Multiline tabs are evil
(I remember loosing all orientation when confronted w/ the
row-swapping in Word 6.0's Options dialog), and scrolling (in general,
and particularly the scrolling-focus in GTK+) is just pointlessly slow
given that a menu is a better idea. Hell, it could even be implemented
w/o changing the API/ABI of GTK+.

First off, let me point out that gtk_notebook_popup_enable() does
something very close to what you are suggesting.

But let me say, if you want a menu, use a REAL menu, and remove the
tabs entierly.  So why then are we using tabs in the first place? 
Because they allow you to see all the pages without moving or clicking
on anything, and they allow you to switch pages with only a single
click.  If there's alot of tabs it may get confusing with multiple
rows, but it's the *only* method that still fulfills the original
intentions of the tabs.

And might I suggest something else?  If it's the confusion from moving
the rows around that's causing problems, then *don't do it*.  Leave
them in place and come up with a way to make it look sane.  It doesn't
*have* to be tab graphics, it could be something else that lays out
buttons to switch pages like that.

*** Bug 112757 has been marked as a duplicate of this bug. ***

In Bug 112757 bordoley@msu.edu says:

It would be nice if notebook scroll arrows would be split like this:
[<][ tab 1 ] [ tab 2] [ tab 3 ] [>]

especially in mdi apps like galeon, epiphany and gedit, this makes moving 
between tabs easier. Since if I want to move left its more natural to 
click towards the left side of the window.

Also this would have fitts law advantages, because I would be able to
slam 
the left edge of the screen to scroll left similar to how I can slam the 
right hand of the screen to scroll right when the window is maximized.

I think multiple rows would throughly suck especially in a pseudo mdi 
app like epiphany where i might have 10-15 tabs open which could 
result in two or three rows. Multiple rows don't work for the reasons 
mentioned in the article above. However changing the arrows to move 
as mentioned above would be really nice for the reasons i mentioned. 

Also as far using a menu, in mdi apps such as epiphany, there should 
be tabs menu, and this menu should list any open tabs (we plan to add 
this to epiphany in near future).

Regarding the split scroll arrows, would it be a good idea to do this
like the GtkRange steppers ? Ie support up to four arrows
[<][>][tabs..][<][>] and add style properties to determine which
arrows to show ? Then we could leave the default unchanged, but themes
could switch to the split arrows style.

Mathias,

For theme consistency yeah that would probably be a good idea,
although i do think changing the default arrows to what I suggested to
match the default gtk scroll arrows would be a good idea.

I meant to mention this before, another reason why an overflow menu is
not necessary is that a properly designed mdi app should have a tabs
or windows menu that lists all open tabs. These type of apps are
really the only use case for overflowing tabs. Any preference window
or other dialog that has overflowing tabs is poorly designed most
likely and the bug is in the design of the window not gtk's overflow
handeling.

Here is an implementation of the style property idea. Although it
seems to work fine, the patch can't be committed in its current form
since it breaks ABI compatibility (it increases the size of the  the
GktNotebook bitfield from 16 to 22, likely increasing the size of the
structure). This can be fixed by fixing bug 96834 (remove focus_tab)
and adding suitable padding.

Created attachment 16511 [details] [review]
patch

Notes on mutiple tabs:

 - Personally, I find them ultra-confusing
 - Somewhere (maybe Joel Spolsky's "User Interface Design for
   Programmers") I saw a proposal for an alternative
   designer where you put some rows of tabs above and
   some below to avoid reordering; something like the
   Outlike-style shortcut bar, but with tabs. I don't
   know how it would actually work in practice.
 - I think everybody agrees that if you *need* them
   (or scrollbar tabs), something has gone wrong
 - You can't do them without height-for-width geometry
   management (bug 104188, hopefully for GTK+-2.6)

Notes on arrow placement:

 - Clearly a HEAD-only change
 - It seems reasonable to me to split them ... should be
   more intuitive that way. In fact, I'd be in favor
   of making the split the default.
 - The addition of bitfields at the end of the structure
   should be harmless, even going from 16=>22. The reason
   why is that architectures with aligment needs (all of
   them, really) will have to pad out structure sizes
   to alignment boundaries so you can have

    GtkNotebook notebooks[10]

   and have all the members aligned. But for HEAD, could
   also be done with IPD. Trying to do it by replacement
   focus_tab is at least as dependent on "reasonable"
   alignment for the architecture as adding them at the end.
 
   We added a flag at the end of GtkTreeViewColumn for
   2.2, in fact.
 - 'arrow = arrow & 3' is really yucky. At the least
   there should be a macro to encapsulate that defined
   next to to enumeration. I'd probably also use
   a named enum rather than an anoymous one to avoid
   guint arrow_type.
 - I haven't really looked at the drawing code, but
   if it works in practice for all four orientations
   it's probably fine.

Here is a cleaned up patch which also makes the split setup the default.

Created attachment 16747 [details] [review]
cleaned up patch

Looks fine to me, as far as I can tell from reading the
patch. We'll hope that nobody was looking at private
fields of GtkNotebook

-  guint in_child           : 2;
-  guint click_child        : 2;
+  guint in_child           : 3;
+  guint click_child        : 3;
   guint button             : 2;

Committed to HEAD.

Why is this bug closed?  Isn't changing the arrow locations a seperate
bug?

because multiple tabs are considered bad usability, and the solution
provided here fits the needs of mdi applications. Where the biggest
problem existed with large number of tabs.

Huh?  The arrow location is a completely superficial change, and does
little to change the usability, and it's not a solution to the bug at
all.  Bug 112757 should be a seperate bug, and only it should be
closed.  I have no idea why it was marked as a duplicate.

I agree that the duplicate was a little dubious (I think
that the idea was that they were both "dealing with many
tabs" issues)

But would it really make you happier if we reopened this
one, reopened that one, resolved this WONTFIX and 
resolved that one FIXED?

I don't think any of the people posting to this bug
report other than you have expressed interest in 
adding windows-style multiple rows of tabs to GTK+.

Reopening it and making it depend on Bug 104188 would make me happy.

Bottom line is that, as poor as you may consider multiple rows to be,
it's the lesser of two evils when compared to scroll arrows.  And if
there's so many tabs that we can't show them all on one line, it's the
USER that's at fault.  Why do you want to punish the user for having
multiple documents open?

No its not the lesser of two evils. If you are using an mdi
application that doesn't have a windows/tabs menu listing all the open
tabs, than the app is broken. 

If you are using a pref dialog or other window that has a fixed number
of tabs that don't fit in the window, than the dialog design is borked.

In either case this is not gtk's fault or problem. Gtk shouldn't
provide a proven broken ui.

I *definately* would rather see multiple rows of tabs find its way
into this eventually. The demand shown for tabbed browsing in projects
like mozilla should make it clear that tabbed applications are not a
function that will go away any time soon. In particular, these cases
where a variable number of tabs will be completely unpredictable at
design time neccesitates some functional way of managing large numbers
of tabs. Multiple rows means that the user can go directly to the
document they're interested in with one click, and can see all the
relevant documents (and their status in the cases of
galeon/xchat-style tab highlighting) simultaneously.

I haven't seen any good argument for how hiding the tabs that can't
fit in a single row behind what is in effect a cleverly disguised
scroll pane makes them any more accessable to the user :)

I can see the idea of discouraging tab-complex dialogs by not
implementing multiple rows, but I really can't see the logic behind
forcing that bad UI on multiple document/view/channel tab users just
to keep up the pressure on tab-happy dialog designers to simplify
their UI.

If you're going to put all your document views into a menu like that,
why have tabs in the first place? Tabs are a big deal in browsers
specifically because they keep all of what you're looking at in a
readilly available interface. Putting them into a menu instead is
exactly the opposite of that isn't it?

The reason I marked the other bug a duplicate of this was that *both*
arrows and multiple rows doesn't make sense.

I'm not convinced this arrow change is right. The Fitt's law argument
doesn't really work, because when you first decide to scroll, you will
have to hit a small point far away. Putting that small point against
the edge of monitor doesn't help much; it's still a small point. Sure
it has "infinite width", but the height is as much a bottleneck here
as the width.

With the new placement of the arrows, if you want to scroll the other
way after having scrolled one way, you'll have to hit _another_ small
point far away. With the arrows close to each other, at least the
other arrow would be easy to hit.

Soeron:

The convenience with the arrows being split is for users who are goin
through tabs left of the current one. If you are at the left most
visible tab with more tabs left of it, its much more convenient (and
natural) to try to hit an arrow left  of where you are pointing than
to move right, trying to pinpoint a small arrow in between the move
right arrow and the close button. (this is for mdi apps).

The fitss law point does work here but only applies to when a window
is maximized. hell if the scroll arrows where in an of the screen
corners they could be just one pixel big and still be easy to hit, but
being able to at least not have to aim horizontally when trying to hit
scroll arrows while maximized is nice.

I'm not too concerned about Fitt's law here; my main reason
for favoring the split tab positioning is that if overflowing
tabs is an unusual situation (and it really should be) then
the primary goal should be clarity. And I think an arrow
on the side where there are more tabs is a lot more obvious
than two arrows in the upper right. Also, it makes sense to
be consistent with the default GtkScrollbar appearance.

As far as MDI tabs; you really don't want multiple rows
of tabs there ... look instead at what Mozilla does when
you get too many tabs; it shortens the labels of all
the tabs.

(Supporting that is very much a separate issue ... not part of 
this bug)

If anything I'd say that shortening tabs to fit a window is even worse
then a pseudo-scroll. For a sufficient number of tabs, each and every
tab becomes completely useless.

I still fail to see a convincing argument why multiple rows of tabs
for MDI applications is sub-optimal at all in the case where a large
number of tabs must be open given a particular use case. No other
solution I've seen or heard of makes all tabs accessible in a single
(or far that matter, a fixed number) click, and no other solution
presents the status of all tabs simultaneosly. Tabs in
xchat/gnomechat/galeon would be substantially harder to manage if you
couldn't tell at a glance which tabs had new data waiting.

I may sound like I take this kind of personally, but I do. The simple
fact is: as a user, when I need a large number of tabs in
xchat/galeon, the scrolling-tab solution absolutely does not work to
my satisfaction. I *need* to see all the tabs I'm working with at
once. I end up using obscure setups to run multiple instances of xchat
on different workspaces, and I use several galeon windows, just to
make sure that I have enought horizontal room for my tabs. Or worse, I
just give up and use fewer irc channels at once, which I suspect is
the reaction of most xchat users (at least the ones I've spoken to).

Reopening this bug, gonna close the other one.

Nevermind the other bug, just leaving it as RESOLVED DUPLICATE

*** Bug 115931 has been marked as a duplicate of this bug. ***

I've made bug 125250 the bug for tab label ellipsization.

This is safe to not make 2.4 at this point.

*** Bug 148316 has been marked as a duplicate of this bug. ***

I can somewhat relate to this as the panel menu-list is annoying for me. I don't
want it to group the same apps together because it's much easier to recognize
the window I want when it's listed straight across (just like tabs). However the
implementation of multiple row tabs (as I have seen it), is always confusing and
not very optimal. When clicking on a tab that is in a different row, the rows
change and then your mind has to figure out where all the tabs have moved to.
Ideally you would want it to work without movement of rows, so this I've been
pondering this and this is what I came up with:

R1: [Tab1][Tab2]...

Then when the row is filled and another added maybe something like:

R2: [Tab17]
R1: [Tab1 ][Tab2]...

Logically you would want to think that the current tab should be "attached" to
the current page, because this is how we see them physically. But the real world
doesn't quite fit into the computer world. Having many tab pages in real life
mean that you have to actually search for the one you're look for or open
another cabinet. The above sort of simulates another cabinet with R2, but
cabinet one stays where it originally was. Also the rows should be aligned so
that you don't get:

R2: [Tab17][Tab18][Tab19][Tab20]
R1: [Tab1][Tab2][Tab3][Tab4][Tab5]...

Because that makes things harder to recognize as well, instead it should be:

R2: [Tab17][Tab18][Tab19][Tab20]
R1: [Tab1 ][Tab2 ][Tab3 ][Tab4 ][Tab5]...

Maybe this was already your idea? I don't know, so I thought I'd share my views
on the matter. To me the purpose of tabs is to quickly be able change the
view/document to another view/document in the same application (though I think
this is valid for the panel as well).

Just to throw out some more ideas as for some reason I keep ending up getting to
this bug in some application. For me it is much easier to use tabs with no text
on them (shortening tabs), rather than clicking the > arrow to scroll through
all the available tabs as that seems to take a lot longer. But that's not why
I'm replying...

What if the tab row ended with an ellipses tab that could expand, such as:
[ Tab 1 ][ Tab 2 ][ Tab 3 ][ Tab 4 ][ ... ]

Then clicking on the ellipses would bring up all the tabs (almost like an expose
type thing), such as:
[ Tab 1 ][ Tab 2 ][ Tab 3 ][ Tab 4 ][ ... ]
[ Tab 5 ][ Tab 6 ][ Tab 7 ][ Tab 8 ][ Tab 9 ]
[ Tab10 ][ Tab11 ][ Tab12 ]

Hmm, maybe it would work. Or maybe it might generate some better ideas. Almost
anything is better than the current scroll across the top.

I consider this a MAJOR usability bug that should be addressed asap. 

As I understand, when the tab row gets full there are two viable solutions: 

1) Use shortening tabs (like mozilla)
2) Use multiple rows for displaying tabs

As the above user notes the best is probably the combination of both. That is, use shortening tabs unless a special button next to the tabs is pressed, which expands them in multiple lines. 

Can't a developer address this issue? Imho, it should even be classified as a blocker bug for the next GTK+ release!

> 1) Use shortening tabs (like mozilla)

That would only help you from about 4 to 10 elements (depending on your resolution); if you try to have more than 40 browser tabs open (which actually happens regularly for me) the mozilla way gets a lot more broken because I cannot read a single tab label.

(In reply to comment #41)
> > 1) Use shortening tabs (like mozilla)
> 
> That would only help you from about 4 to 10 elements (depending on your
> resolution); if you try to have more than 40 browser tabs open (which actually
> happens regularly for me) the mozilla way gets a lot more broken because I
> cannot read a single tab label.

Right! However some times I don't care about tha tab's label because I read all tabs sequentially. That's why shortening tabs and multi-line tabs should be interchangeable via a small button next to the tabs. This way users can choose what suits them best. 

How about searching for a solution in directions like:

- if there are overflowing tabs, display the right half of the first overflowing tab on the left side / the left half of the first overflowing tab on the right side, like this:

...ab 8] [Tab 9] [Tab 10] [Tab 11] [Tab...

that way people can see that there is more and it won't appear that a tab has simply vanished.

- if there is more vertical space than horizontal space, dynamically switch to vertical tabs on the side when horizontal tabs start to overflow

- use sliding effects similar to toolbar widgets, to indicate that tabs are moving out of sight.

Wouldn't narrow tabs be a better solution? Firefox and opera both have these (where a lot of tabs are just shrunk in width, but without multiple rows or arrows), and it's ways better than the current arrow implementation.

just for reference, the URL in #c1 should be:

  http://homepage.mac.com/bradster/iarchitect/tabs.htm

as for #c44 - you should read #c42 on why shortening tabs really break down the usability when having lots of tabs (which is really why this bug was opened in the first place); thus, shrinking tabs is not a solution.

@#45: perhaps, but this should act like the toolbar buttons. The behaviour should easily be set from the gnome-ui-properties, even if the shortened tabs are not the default.

My feelings:
1) Arrows on the side have /very/ low usability.
2) "Shortening tabs" greatly enhance usability.
3) The point where shortening tabs become too short varies with person and application:
   a) Some people here indicate they must at all times see all info in a tab.
   b) Other people (me included) are fine even with tabs without any info.
   c) Tabs without info are good in a browser when serially going through them.
   d) Tabs without info in an application like xchat are probably bad. 
   e) An application like Firefox also has as an advantage that the website
      icon in the tab remains indicative of the contents even at small width.
4) Adding rows can be good (depending on the app), but:
   a) Steals my desktop real estate; I HATE that.
   b) Does not solve the problem in case of quasi-infinite tabs (so why bother?).

My summary:
1) The variation with person and application, combined with the Gnome wish to have one solution that works for all is what hurts in this bug.
2) The current arrow solution should die or the arrows should be much larger.
3) Shortening tabs should be implemented.  The cap on minimum size should have a Gnome default, but be modifiable by the application (e.g. Xchat knows it needs more width than a browser).
4) If the number of tabs does not fit anymore, do:
 [<-...ab 8] [Tab 9] [Tab 10] [Tab 11] [Tab...->] like in Post 43, and let the tabs (smooth) scroll perhaps already when the mouse hovers over the chopped tab on the side.  No clicks needed that way.

Hey all.

This seems like a long and interesting discussion.

Here is my problem with the current _function_ of the arrows. I'd rather have arrows, that rows of tabs, BTW.

I'd have it so when the user hovers (or clicks) on either arrow, the current tab should not be defocused and a new one refocused, rather just the viewable part should be affected.

For example.

If the tabs are like this (*tab3* indicates focused tab):
[<][tab2][*tab3*][tab4][>]

then, when the user hovers the mouse over the left tab, the view should change to this (with *tab3* still being the focused tab):
[<][tab1][tab2][*tab3*][>]

Cheers,
-Gezim

The bug 377441 should implement Gezim's idea.

The "Tab Mix Plus" addon for Firefox implements all the ideas expressed in this discussion:

- shrinkable tabs
- multiple rows
- left and right arrows

We can configure a lot of options, like:

When tabs don't fit width: Multi-row or Scrollable with buttons
Max number of rows to display if multi-row is selected
Tab width
...

For example, we can choose a 200 px width for the tabs, but if we add more tabs, they can shrink until 100 px, then if we add again more tabs, they can use more than one row (for example until 3 rows), and then if we add again more tabs, the left and the right arrows appear for the tabs exceeding the 3 rows.

Which solution is right will depend on how the widget is being used in the application, and in some cases the user's own personal preference or circumstance.

I think GtkNotebook should be made capable of doing these different things, and the application developers should make the design decisions, including which choices to give the user as preferences.

*** Bug 631219 has been marked as a duplicate of this bug. ***

Why you won't fix it?