dwm FAQ
dwm is a popular tiling window manager designed with minimalism and efficiency in mind. I am the lead developer of one component, dmenu, and I help out with the window manager proper. A few of the common complaints we get about the software come from a fundamental misunderstanding of how dwm works. I hope to clear some things up here.
Why don’t tags remember their layout?
Tags ≠ workspaces. This is very important. Requests are sometimes made that the pertag patch be applied to mainline. However, pertag simply does not make sense: one of the most powerful features of dwm is that you can view multiple tags at once. When you view a tag you are not ‘visiting’ a workspace, you are pulling the tagged windows into a single workspace, which has a single active layout. There is no layout associated with any tag, because a tag is nothing in and of itself, it is just a label you can assign to windows.
Once you realise this distinction it will help you to understand why certain behaviours you may not have understood are not bugs, but a feature of this far more dynamic window management. For example, if you have two windows, each assigned to the same two tags, and you ‘zoom’ one to master (Alt-Return), and then switch tag, the window has been zoomed on the other tag, too. Of course, the reason for this is that there is no ‘other tag’: when you toggle tags you’re just asking to see the exact same windows, nothing else — of course they don’t move!
All dwm is is a list of clients, each with a set of tags. When you ‘zoom’ a window, you’re just moving it to the top of this list. And when you view and hide tags, all you’re doing is viewing and hiding subsets of this list. There are no workspaces, no other forms of ordering, it’s just a long list of tagged clients. That’s why dwm behaves the way it does, and that’s why it may have been confusing if you’ve been looking at it from the wrong angle. However, those of us who have been using it a long time are very fond of this behaviour, and once you get into the flow you may find that it really works well.
Why can’t I create and destroy tags?
Tags aren’t actually implemented as any kind of object, they’re just a bitmask on each window which describes with which tags, 1 to (up to) 32, the window is tagged. These tags just happen to have names, and you can always access them because the keybindings are set at compile time in config.h. So the real question is: why are they visible when I’m not using them? Well, it doesn’t make sense other than for saving screen estate, but you could hide those not in use. But it makes more sense as a default to show all your available tags. You may also want to look at the nametag patch, which lets you change tags’ names at runtime.
I would personally rather tags had no names, and only those you access with some keybinding would appear, with the appropriate number. I think that would clear up some of the confusion surrounding tags.
Why not fix tags to be more intuitive?
The only intuitive interface is a nipple. We don’t intend to optimise our software for those who just haven’t used it yet; if we did we’d end up with WIMP, and there are plenty of those already.