Re: Tabs

[Teika Kazura <teika lavabit com>]

Hi.

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. 
(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? 

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.)

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.

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.

5. General reminder. You may well understand this, but (a) better 
design makes the job easier after all. Especially for complex ones.
(b) think what's needed -> user interface & backbone -> 
code backbone -> code user interface. UI is important, (that's why
you need WM), but less in implementation. (c) this requires you to
classify things, necessity, option or core, etc, and put priority.
(Learnt so in kindergarten? Yeah. :)

Teika kazura