On Tue, Nov 1, 2011 at 7:36 AM, Rob <robpill...@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. 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... > > Cheers, > Rob >
