Re: Speaking of NSTabView...

[Jeff Teunissen]

thisguyisi wrote:

[snip]

> I don't know how far you've looked into the "more tabs than space"
> problem, but one possible model is Mozilla Firebird, with the Tabbrowser
> Extension loaded. From a visual standpoint, anyway. When there are more
> tabs than will fit on screen, a scrollbar pops up beneath the row of
> tabs, and the view scales to make room for the new scrollbar.
> 
> This visual behavior fits in with GNUstep as it follows the same
> behavior that Preferences.app does when there are more icons than will
> fit in the window; a scrollbar appears below the icons to allow you to
> access the icons outside the current view. The only difference, of
> course, is this deals with an array of tabs, rather than an array of
> icons.
> 
> I'm suggesting this as a solution, because when the scrollbar first
> popped up under the row of tabs while browsing with Mozilla Firebird, I
> thought, "Hey... How NeXT-ish. Cool!"

That's actually _extremely_ non-NeXTish. In a NeXTish UI, anything that can
potentially be scrollable must always have a scroll area displayed, even
when there isn't enough content to make a scrollbar appear.

That's actually a Windows-ish thing, where the text in a text area must be
reflowed if it becomes long enough to have a scrollbar. No such thing
happens in NeXT-like UIs, because the scrollbar appears in the area that has
been designated for it.

Adding a scroller for tabs would be, ahh, confusing (especially considering
that a tab view really "wants" to be the window's content view).

A tab view should be the main content view of the window it is on, and with
only one bevelled edge. That one bevelled edge should be the transition
point between the tabs and the content view. The currently-selected tab
obviously has no bevel.

So the window looks something like this: (ASCII art, use a monospace font to
see properly)
 ________________________________________
|_o_______________Window_______________X_|
|  _________________ __________________  | <-- this area is dark
| /      dark       X       light      \ |
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯                    ¯|
|                                        |
|                                        |
|                content                 | <-- this is light
|                                        |
|                                        |
|________________________________________|
|__|__________________________________|__|


The main type of "scrolling" that makes sense for a NeXTish NSTabView is two
half-tabs, one on each side. If you add a tab to the right side and the
minimum width of the tabs becomes wider than the view's width (this should
_never_ happen, but if it does it should be handled), a partial tab with no
right edge (containing the string "...", or an image of an ellipsis, or an
image of a triangle pointing in the direction of scrolling) should be
displayed.

This pseudo-tab should "scroll" the tabs by repeatedly removing the
left-most tab from the display and checking whether or not there is enough
room now. At this point, if any left tabs were removed from view, you get
another pseudo-tab on the left.

Something like this:
 ________________________________________
|_o_______________Window_______________X_|
|  ________________ _________________ ___| <-- this area is dark
| /     dark       X       light     X . | <-- "arrow" tab is dark,
|¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯                   ¯¯¯|
|                                        |
|                                        |
|                content                 | <-- this is light
|                                        |
|                                        |
|________________________________________|
|__|__________________________________|__|


A key point here is that _all_ displayed tabs (except for pseudo-tabs) are
shown with the same widths, and set up to use the entire width allocated for
them (minus any overhead imposed by the scrolling tabs).

This means that the narrowest width for any displayed tab is equal to the
width of the widest one being displayed. If you have nine tabs, eight of
which are an inch wide and one which is more than half of the width of the
tab view, that ninth tab can _only_ be displayed by itself -- because there
won't be enough room to display two tabs with that same width.

The moral of this story is: Make your tab titles as short as you can
reasonably make them, and try not to make too many of them.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/