On Tue, Nov 1, 2011 at 12:11 AM, lolilolicon <lolilolicon_AT_gmail.com> wrote:
>
> Actually, `apply_lt` can be removed, since `apply_mslts` does the same
> thing when nmaster == 0. I'm thinking of making nmaster a member of
> the Layout structure, instead of the current Monitor. This way, we can
> make all windows slaves in the `grid' layout, while having two masters
> when we switch to `tile'. The same applies to mfact- the `ncol' layout
> certainly needs a bigger mfact than `tile', for example. Finally, neither
> nmaster nor mfact makes sense in non-master-slave layouts (if you still
> use those, that is ;). Oh, and it would be nice if mfact increased when
> nmaster increased in the `ncol' layout, too. Maybe another function
> as a member of Layout, which would be executed to set mfact as a hook
> whenever nmaster changes?
>
Indeed mfact and nmaster being members of Layout does make more sense, and
I made a patch which includes this change.
Since I don't know much about hg, I just did a `hg export`, and attach the
produced patch as attachment instead of inline. The commit message should
describe what has been done, and the code should explain itself.
Note that this may seem to add some SLOCs, but it actually reduces the
amount of code required to implement the same layouts by avoiding code
duplication. See how tile, bstack and col are each defined using just a
one-liner. By defining two layout algorithms `lt_vstack` and `lt_hstack`,
in combination with the hsplit switch, one can define 2 ** 2 * 2 = 8 such
layouts, and if you count the (masters|slaves)-only layouts as separate
ones, we got 10. Add a third layout algorithm, and you have
3 ** 2 * 2 + 3 = 21. Sure, not all layouts are useful for everyone, but
hopefully this will produce some interesting layouts suitable for your
particular setup.
Received on Tue Nov 01 2011 - 00:07:40 CET