Re: [dev] Re: [dwm] A general approach to master-slave layouts

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 1 Nov 2011 11:20:58 +0100

On 1 November 2011 00:07, lolilolicon <lolilolicon_AT_gmail.com> wrote:
> Indeed mfact and nmaster being members of Layout does make more sense, and
> I made a patch which includes this change.
>
> 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.

Thanks for you patch, I looked at it and it is indeed interesting.
However it needs further testing and review in order to be a candidate
for mainline at some point.

Some remarks:

The change of the Layout struct makes it a lot harder to define
layouts, as now one also has to understand the variables
nmaster/mfact. Also nmaster/mfact are now layout specific variables
that might not be used by other layouts. This lacks a bit conceptual
clarity imho.

What I'd really prefer is keeping the interface intact we had, a
layout is just a function -- I have no objections that this function
calls other functions or set up some variables to fit its needs. This
would keep it equally simple to the user to define Layouts and leave
the interface to be a function, rather than a function + variables.

Also I'm not absolutely happy about the introduction of the Booth
struct, I would rename that into Rect as we have used a similar name
in other areas. Having said this, I'm in favor of *not* using
XRectangle where possible, in order to keep the core code of dwm X
agnostic (which is one 6.0 goal btw).

Cheers,
Anselm
Received on Tue Nov 01 2011 - 11:20:58 CET