On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe <garb...@gmail.com> wrote:
> On 1 November 2011 00:07, lolilolicon <loliloli...@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.
>
Can't agree more.
> 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.
>
I also agree with what you said here, but let me clarify my intention.
I really think it more useful to make mfact/nmaster layout-specific,
otherwise I wounldn't have made the change to the Layout struct. For
example, on my 1280x800 screen, mfact == 0.75 combined with nmaster == 2
in the n?col layout makes a nice layout, but the combination is very
bad for the tile layout. As such, sharing mfact/nmaster across layouts
isn't exactly nice, nor is it "dynamic" enough.
But now I realize another problem with moving mfact/nmaster to Layout.
The issue is two monitors should be able to use different mfact/nmaster
values for the same layout; also, the setmfact/incnmaster functions
will not update the unselected monitor, but will have their effects all
of a sudden next time that monitor is arranged.
This makes me want to make nmaster/mfact specific to the monitor *and*
the layout. And I also prefer achieving this in the least intrusive
way possible.
> 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.
>
You are absolutely right. Now that I think of it, we can temporarily
set m->mfact and/or m->nmaster in a layout function before calling
apply_mslts, and restore the values afterwards. For example, define
the col layout like this:
/* int term_width is the width of a terminal (e.g. 80 characters) */
void
col(Monitor *m) {
float mfact = m->mfact;
int nmaster = m->nmaster;
/* masters will be term_width wide */
m->nmaster = MIN(nmaster, m->ww / term_width);
m->mfact = (float)term_width * m->nmaster / m->ww;
apply_mslts(m, False, lt_hstack, lt_vstack);
m->mfact = mfact;
m->nmaster = nmaster;
}
A bit back-and-forth with the mfact calculation (since we will calculate
back to the width in apply_mslts), but it's a fair compromise, I guess.
> 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).
>
Bah, Booth is cute! Just kidding; I knew it would sound strange and
probably have to be renamed. Here we go, Rect it is.
> Cheers,
> Anselm
>
>
