Re: [dwm] cycling through tags?

From: Joerg van den Hoff <>
Date: Fri, 1 Feb 2008 09:03:23 +0100

On Thu, Jan 31, 2008 at 10:02:18PM +0000, Andrew Oakley wrote:
> There is some question of what it would mean to move to the next tag
> when there are multiple tags selected. However, for a given definition
> of "next tag" it shouldn't be too hard to code.
> I don't think code like this should really be included in dwm - the
> question of what "next tag" means really is debatable, and people can
> easily hack it if they want.

I'm thinking of the workspace-like situation where you view
one tag-group of a certain index 1..9. then 'next' and 'prev'
is rather well defined.

> At the top of dwm.c, with the other declarations:
> void nexttag(const char *arg);
> Somewhere further down (doesn't really matter where) in dwm.c:
> void
> nexttag(const char *arg) {
> unsigned int i, j;
> memcpy(prevtags, seltags, sizeof seltags);
> for (i = 0; i < LENGTH(tags); i++) {
> if (seltags[i])
> j = (i + 1) % LENGTH(tags);
> seltags[i] = False;
> }
> seltags[j] = True;
> arrange();
> }
> In your config.h keybindings:
> { MODKEY, XK_n, nexttag, NULL },
> Obviously you would want to write a prevtag function as well, and
> probably make sure my code works (I can't say that I've actually tested
> it). In any case, this is the beauty of dwm - it really doesn't take
> long to hack it to do what you want.

only very recently I gave `dwm' a closer look (having used `ion' for
quite some time now). without question the minimalistic approach
and economic implementation is attractive. I especially appreciate
that `dwm' compiles "just so" on different platforms (quite the
contrary with `ion'). having said this, I
definitely don't believe in configuring a window manager by
editing the source code. at the very least, this seems to imply
that one starts over and over again with each new release (or
one has to verify that the config header default layout has not
changed. I would stil be in favour of some simple(-minded)
configuration file of the keyword/value variety (or even activating
this by a compile flag only, leaving the defaults defined in config.h).

w.r.t. hacking it to your needs: it probably is nice that it's
"easy" to do so. but I'm conservative here: I believe in canonical
"offifical" releases (which might include of course the sensible patches
from the users). the same holds true here as it did above: if I start
(and am able) to mess with the source code, get some desired functionality
running (such as, e.g. the cycling through tags), it will be gone
with the next release and I have to start thinking about putting
my additions in a separate source file (or lib), check that
the function interfaces are unmodified in the next release etc etc.

that's no good if I'm actually "only" a user of a nice window manager
who needs to get other things done.

while I absolutely appreciate the striving for a small code base, maybe
one could think about adding a modular aspect (added functionality
in optitional (small!) libraries), where `dwm' still compiles and works
without the libs but including them adds stuff (like the current
example of cycling through tags). if this were supported by the author
there would be some guarantee of working interfaces across releases.
if I look at the home page there a quite a few nice extensions to `dwm'
which are tied to specific releases and are simply left behind while
dwm is developed further. I think this is a pity.

is all this wrong?

> If the suggestion I've made doesn't work, I could do it properly, test,
> and post a patch if you like.

thanks a lot so far. I'll keep this and test it when I find
the time (too busy right now) and let you know. if I read the
code right the cycling enacted by the modulo expression is exactly
what I mean.

thanks again,


> Joerg van den Hoff wrote:
> > simple question:
> >
> > there seems to be no pre-defined way to cycle forward/backward
> > through tag-groups (still essentially a.k.a. workspaces to
> > me, though I understand there's a difference). only mod1+[1..9] and
> > mod1+tab seem to be in place for navigation. from my experience
> > with `ion' I find the cycling (next/previous) between workspaces most useful,
> > especially when searching for a certain window.
> >
> > question: can (and should) it be done?
> >
> > joerg
> >
> >
Received on Fri Feb 01 2008 - 09:03:25 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 15:17:59 UTC