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

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 1 Nov 2011 12:39:14 +0100

On 1 November 2011 02:10, lolilolicon <lolilolicon_AT_gmail.com> wrote:
> On Tue, Nov 1, 2011 at 7:36 AM, Rob <robpilling_AT_gmail.com> wrote:
>>
>> I don't have much time today, or possibly tomorrow, but I'm interested
>> in this patch, it sounds almost like it recurses on each sub-section of
>> the total area, applying a different layout function each time, except
>> it's limited to two calls, one for the master area and one for the
>> slave.
>
> It's only one patch, which I sent in my last mail, so not much really :)
>
> The core is the `apply_mslts' funtion.  It walks all clients like any
> tiling layout would do, e.g., the `tile' function defined in the patch
> simply calls `apply_mslts(m, False, lt_vstack, lt_vstack)`, and it should
> do the layout exactly the same way the original `tile' would do, no extra
> wasted work.  The code should be clear, but maybe note that the mltf/sltf
> functions modify `c'.
>
>> Either way, I'm hoping to try out your patch(es) at some point
>> this week, and hoping to mess around with the key bindings, I assume you
>> can change the master layout while keeping the slave one the same with a
>> binding, right?
>
> Not really.  DWM knows only about a single layout per monitor, even if we
> set the masters to temporarily use a different layout algorithm, but not
> update the currently selected layout name, DWM will rearrange the masters
> back to the selected layout whenever arrangemon() is called, which happens
> probably before you realize it ;).  That said, you can always define two
> layouts which differ only in the master layout, (e.g. `tile' and `col').
> Or if we feel progressive, let's make DWM aware of the master layout as
> well as the slave layout, although I don't see practical need so far.

This progressive approach will lead to two layout actions in a single
view just for a subset of layouts. Overall this will make the usage
much more complicated which is why I would not implement it in
mainline dwm. See my other mail, I suggest making the layout approach
more direct through (re)setting nmaster/mfact in the layout function
as precondition. I'm not totally opposed to have manipulators of
nmaster/mfact optionally though.

> Similarly, I also considered to enable toggling master/slave splitting
> direction, effectively "rotating" the layout, or even allow "flipping",
> but then thought it not useful in practice...

Nah, don't go there. At the end of the day the user applies a
particular layout he feels comfortable with. If the user ends up
fiddling with the layout algorithms all the time then we did something
seriously wrong.

We should never forget that it is the window managers job to manage
the windows, not the users job. Even having a mfact manipulator as of
today does violate this paradigm already a bit.

Cheers,
Anselm
Received on Tue Nov 01 2011 - 12:39:14 CET