Re: Tabs

[GSR - FR <famrom infernal-iceberg com>]

Hi,
teika lavabit com (2008-12-29 at 1418.35 +0900):
> GSR's previous message provides us a good basis. Let me supplement 
> some points.
> 1. Terminology is needed for some confusing ideas. 
> 'Tab' can mean: the tabbed window, the tab group, the 'sub-title bar',
> namely the lesser bar which prints the name of the tabbed window,
> and when clicked, it chooses the tabbed window. (The original meaning
> of the word 'tab' is this.)
> 'Tabbed window', 'tab-group', 'Group window' and 'group frame' 
> seem acceptable. A proper word for 
> 'sub-title bar', or rather, the idea itself should be settled. 

Tab bar would be the zone (or "the tabs"), and each item a tab,
keeping the original meaning. No need of redefinition, but as you more
or less realized, for me those are visual things, theme specific.

> (For sub-title bar, I imagine the one in firefox. GSR seems to think
> differently on it. Explained later.) 
> They should be fixed, at least temporarily.
> Are there any other instanecs than tab? 

"Instances" of what?

> 2. Kepmaps. Yes, you'll need more key bindings for tabs.
> But a pass-thru mechanism can effectively reduce them; 
> suppose we bind ctrl+PageUp for 'previous tab'. But it'd be nice 
> if when it is pressed on a non-tab window, then it is passed 
> to the window. (This doesn't solve all the problems, though.)

Never done that, other than simple replay pointer events. Thanks for
mentioning, another detail to make sure the system has or at least
allow in future expansion.

> 3. 'sub-title bar': GSR seems to think themes take care. It is nice,
> but it can be optional. If a theme doesn't provide this feature,
> then the fallback(s) is provided by the core sawfish. Options can
> be added later.

Well, I went what it Sawfish style: if theme does not support
something, it probably works (iconify function, ie), you just do not
get the visual feature (iconify button). Themes are already not caring
about side frames (any nextstep look alike) or titles (zerobaby) or
all kind of button combinations (only a few show all buttons or allow
configuring them). ;]

So for tabs this does not mean you will not have the core idea
(grouping) just that you will have no tab button and/or zone with
tabs. Having a visual fallback does not fit with how all other things
are done, but the biggest issue I see is that it will overcomplicate
the system (choose place, colours, etc that half work... not easy).

And simplest way to support tabs for everyone, ship one tabing theme
so it can be used. It avoids mixing frame trickery into the system,
and provides a good demo for other themes. In the end, integrated in
the code or by means of an official theme, it is going to look "out of
place" with many other themes, so I prefer a cleaner code separation
and no visual assumptions in the back end (vertical tabs? multiple
rows? fine, theme is in charge).

> 4. (minor point) Window cycling. It seems more natural that window
> cycling treats a tab group as one, but some people may prefer that
> each tabbed window also gets cycled.

Good point, so we have remember to provide the option. Implementation
can be done by temporarily removing from cycle list or checking in
cycle if the window is not front one for a tab group.

GSR