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

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 1 Nov 2011 16:38:52 +0100

On 1 November 2011 16:27, lolilolicon <lolilolicon_AT_gmail.com> wrote:
> On Tue, Nov 1, 2011 at 6:20 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
>> 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.

Exactly this is the main problem. You could work around it with
changing monitor as follows:

 struct Monitor {
        char ltsymbol[16];
- float mfact;
- int nmaster;
+ float mfact[LENGTH(layouts)];
+ int nmaster[LENGTH(layouts)];
        int num;
        int by; /* bar geometry */
        int mx, my, mw, mh; /* screen size */

however this would require some reshuffling of the config.h inclusion
and also changes in various places. So I doubt it would be necessary
at all. Just stick with nmaster/mfact in Monitor.

>> 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.

This could work for a patch, but I don't think this is a great way of
programming for mainline, since manipulating and restoring
nmaster/mfact for the time being is quite ugly. ;)

Cheers,
Anselm
Received on Tue Nov 01 2011 - 16:38:52 CET