pancake <[EMAIL PROTECTED]> 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.