Hi, [email protected] (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
