Re: Tabs bug: inactive tabs being overlapped





On Thu, Aug 7, 2008 at 9:21 AM, Fernando <ferkiwi gmail com> wrote:
On Thu, Aug 7, 2008 at 2:41 AM, GSR - FR <famrom infernal-iceberg com> wrote:
Hi,
sawfish-list toykeeper net (2008-08-06 at 1748.23 -0600):
[...]
> > I can't see how someone would ever want to use groups and tabs
> > simultaneously and independently (since groups are just like
> > tabs that are not attached to each other).
>
> 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"...

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

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.

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.

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]