Re: Tabs bug: inactive tabs being overlapped

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

[Sorry for slow reply]

Hi,
ferkiwi gmail com (2008-08-07 at 1017.17 +0200):
> >> > What do groups actually do?  Who uses them?
> >> There are special commands and settings that work with them (,apropos
> >> "group" as start). I would make tabs separate instead of overloading
> >> groups to avoid things going nuts (imagine you want to group GIMP
> >> windows, but not all in same tabset, but a couple of them).
> I've kept thinking about it and.. I think that what would really be an
> overload for sawfish and a confusing thing for most of the users would be to
> have a lot of commands of the kind of "cycle group" "cycle class" "cycle
> window" "cycle tab" "cycle viewport" "cycle workspace"...

Sawfish is overload by definition. ;] We do not try to push things as
"this goes with this and you will have to get both" but try to provide
a flexible system so it can be as much as the user wants, even leading
to new uses nobody thought about before (IOW, for fixed sets, better
look for a different WM). We are looking into how to get tab system
into it after all, perfect demo of expanding beyond previous state.

> I think there are already a lot of ways for sorting.. it can get very
> confusing, most people hardly know how to use groups and now they will have
> yet another concept to difference from it... and what's worse, a very
> similar concept (tabs are just like sticked groups).

Tabs are, at least from my POV, a window container, in which all
windows share a place, size and depth. Basically, remove what some
apps are doing and move back to WM level (with the adventage of being
able to tab windows of different apps).
 
> Tabbing is just an switchable option, and anyway we have already quite some
> ways to allow the Gimp+Tabs approach. If a new whole command infrastructure
> was to be created for that I think it would be better to add class-specific
> commands instead of duplicating an already existent infrastructure.

Being switchable does not mean it is allowed to create havok in
others. It should play as nicer as possible with everything, both when
on or off.

> All the windows of Gimp are in the "Gimp" class, so adding a "raise all
> class members when raise window" option or "minimize all class members"
> command would also work. For Gimp and for all the applications with multiple
> windows. There's already a "cycle class" command, why not extend that to
> other things as well?. Anyway.. if that's still not a good solution,
> viewports or workspaces (with matching windows) could be used already
> anyway.

Some of that is already possible (iconify-group-mode eg) and others
are implementable. So from my point of view, the SF way is having all,
instead of trying to hammer things to reduce commands and options...
and down the road, having to fix all the issues created for pushing a
mangled solution.
 
> Moreover, if we were to make tabbed groups a separate thing we well may want
> also to make the same thing for every other property of groups (maybe you
> want a group of windows to minimize as a group, but only want a subset of
> them to raise together). I think it would be messy to duplicate group code
> for each property. If this was to be made it would better be in other way
> (maybe allow a window to be in more than 1 group at the same time).

I think we are showing we do not know how tabs should work and fit
into all other things, but just going ahead with whatever there is,
just because it is already written. Not very wise.

To sum up: I am not against tabs, what I am against is hacking it and
then trying to fix all the issues caused by a really bad start. Call
me old grumpy Sawfisher if you want, but I have clear that SF has to
stand by itself for years to come, as everytime the "could we move to
another with similar features (user extensible, ultra flexible)" topic
appears, the replies lead to "no".

As other have said, adding things, even marked experimental, raises
the expectations, so better not paint us in the corner.

GSR