Re: Tabs

On Sun, Mar 8, 2009 at 1:33 AM, GSR - FR <famrom infernal-iceberg com> wrote:
> First, it was added as wm.tabs.tabs, but IMO it is an extension, so
> should be wm.ext.tabs. Or maybe not, but as cleanup is needed, I
> prefered to move when things are a bit more clear, instead of move
> around every some weeks. I already moved marks.jl, in any case. So
> please no assumptions about current tabs being right or wrong, or an
> example to follow or avoid.

I agree that it's not the perfect model, but I just used it as an
example of module that has its own folder and is self-contained (the
tab commands are all in the tab files). This is not the case of
groups. There is a placement mode for groups in smart.jl, cycling
command for groups in x-cycle.jl, and similar approaches for
iconify.jl and stacking.jl.

Most of this commands would be perfectly fine if added in a different
file loaded for that purpose. The code in x-cycle/smart/etc.. is
mostly procedures for defining different cycle/placement/etc modes,
but the  placement modes are defined afterwards in the same file, if
we want to keep this style we will be forced to modify these main
files each time we want to add a new mode. However...  they also can
be used externally (imported from other files) for the same purpose.
This way it would be possible to have the code organized by modules
that can be enabled/disabled in an efficient way (avoiding to load
unneeded functions), and it would be easier in the future if we want
to follow some of the "Enchancements suggestions in sawfish core" that
the wiki points to.

Even though the tabs and groups are different perhaps some of the
cycle/stacking/iconify or other properties of groups that are mixed in
the other source files could be useful to check out. Although that
would depend on how the tabs are going to be implemented. The current
implementation of tabs, for example, would benefit from using a
similar raise command to the one that groups have (to avoid that other
windows get in the way between the tabgroup).

There are also considerations that would have to be checked about the
combination of groups and tabgroups, like what would happen if we have
2 tabs in the same tabgroup that are members of different groups and a
group command is triggered for one of the groups. And if the raising
of the tabgroup would trigger also the auto-raise (if the option is
enabled) of every group each tab is in.


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