Re: [dwm] [patch] Stack columns patch for dwm-4.4.1

pancake <pancake_AT_youterm.com> writes:

> Here's my keybindings
>
> { MODKEY|ShiftMask, XK_l, setncols, "+1" }, \
> { MODKEY|ShiftMask, XK_h, setncols, "-1" }, \
> { MODKEY|ShiftMask, XK_j, setnmaster, "+1" }, \
> { MODKEY|ShiftMask, XK_k, setnmaster, "-1" }, \

[I.e. interchanging the setncols and setnmaster keybindings.]

Okay, if you think this a more natural extension of the default binding
set, I'll pick this change up back into my own patch. My personal tree
has diverged quite a bit, so in preparing a patch for others to use
against stock dwm, I just copied the config.default.h bindings from the
other nmaster patch out there, and added something by analogy rather than
actually trying to live with the suggested extra keystrokes!

> Some tips:
>
> config.default.h:
> //#define NCOLS 1 /* maximum number of stacking area columns */
> #define NCOLS 1 /* default number of stacking area columns */

Actually, I guess it's the 'default limit to the number of stacking area
columns', as the code won't create ncols columns unless there are enough
windows (more than (ncols - 1)*nrows) to fill them.

> The i < 0 condition has been changed to i < 1 to avoid strange situations.

The ncols setting of zero is intentional, creating as many columns as
required without limit to give exactly nrows clients per row. Maybe
you're right that it isn't especially useful and just adds confusion:
it's indistinguishable from ncols >> 1 for practical purposes.

Originally, my tile() had no ncols limit, and so I needed an nrows of
zero to get the default behaviour of an unlimited number of clients
stacked in a single column. Now I agree, this is less confusingly
achieved by setting ncols = 1, so nrows = 0 can go away.

Removing these two special cases will also simplify a couple of tests in
tile(), which is no bad thing!

> You can check this code here:
> http://news.nopcode.org/pvcroot/dwm-4.4.1-pancake.tar.gz

Glancing through, I notice you've merged in the incnmaster function as
well as my very similar setnmaster function. setnmaster is a superset of
incnmaster, so you probably don't want to also carry the additional code
weight of the latter.

The bstack code could do with supporting the same set of possibilities as
my extended tile. I'll take a look at allowing the master area to be
either above or to the left of the stacking area in my tiling code, and
define two layout functions with the common code pulled out to share. (I
really need to update my personal tree to descend from the single dwm.c
in hg tip in any case.)

Cheers,

Chris.
Received on Mon Sep 17 2007 - 12:17:04 UTC