On Tue, Mar 3, 2009 at 7:58 PM, GSR - FR <[email protected]> wrote: >> I think that a better solution would be to provide a new command >> "cycle-tabgroups" that cycles between the top members of each group. > > And with stand alone windows? Never pick them if using it? Or taken as > tab group with single member?
Good point. In my opinion, it would be more consistent if a stand alone window was considered as a single member tabgroup (tabgroups that have only 1 tab may not display the tabbar). The current implementation of the tabs is done that way. Anyway, in my opinion the current tab implementation should be rewritten. Because the code is quite hacky and it's not well integrated with the rest of sawfish functionalities (for example, you can't use outlines other than "solid" when moving a tabgroup). But before that, I believe that the code should be refactorized a bit. Currently there are many things that could be better organized. For example, there's groups-related code spread through some non group-specific source files (x-cycle.jl raise-commands.jl smart.jl iconify.jl stacking.jl), and the group-specific files are spread in different folders, I believe it would be better to have a "wm/groups" directory to load it as a module, in the same spirit as the "wm/tabs" directory, with the cycling/stacking/placement functionalities loaded using specific files inside the module. And this should probably also be done with other things before adding more functionalities into the mess. I think that the tab code is somewhat related to groups, and maybe refactoring the code would show some light in this issue. -- Fernando
