dwm stands for Dynamic Window Manager, it’s a dynamic tiling WM. Current stable version is 5.9, but I am using version 5.6.1, a two-year-old version, because it’s stable version in Gentoo.
My previous WM is Fluxbox and it’s really a great WM, I had been using it for more than two years. I like it, still do, even now I has switched to dwm. But from time to time, stacking window manager just can make you take some time to move and to resize windows, only to satisfy unnecessary adjustment. It’s as if you wrote one paragraph and take three times of time of writing that paragraph to change text color/style/etc. Like TeX, you are educated to focus on your content, instead. Using tiling window manager, it makes you try less to adjust window size, to align the windows, if you used to line up windows side by side. Many stacking WM supports snapping (dwm does, too), which is helpful for arranging windows, but you might not be happy with the size of the window. So, you go back to maximize all windows, then you might keep pressing Alt+Tab to bring the underneath window to top.
I need to have more than one window to be shown at the same time, tiling would help a lot. And that’s the reason that I switched to dwm. However, dwm wasn’t the first tiling window manager I have tried, awesome was the first. But at the time, I didn’t really get the concept. When I decided to find one to try again, dwm is one of many WM needs very less dependency. No need to learn scripting language, you just use C.
When I firstly tried, I also heard of dwm, but I didn’t want to compile. Now, I prefer to compile a C program instead of using Python script or so. Compiled program should have better performance than interpreted language program. dwm is little more, it doesn’t use a structured configuration file. Actually, a C code is still one, it’s just being parsed and compiled.
Of course, it lacks of certain flexibility since recompilation is required in order to have new configuration, in fact, restart the program is also required. However, the code of dwm is only around 2,000 lines plus your configuration C code, the compilation time is extremely fast. And once you have stable configuration, you probably wouldn’t make and changes for a few months.
I have to admit that this wasn’t my first time to try a tiling WM as I mentioned above. My first experience was with awesome. If I recall correctly, it’s about one week before I switched back to Enlightenment E16. I couldn’t get a hold of tiling WM at that moment, too many keybinds to remember. Funny thing is that I feel I now have configured more keys than I had with awesome. Maybe it’s just I didn’t understand the concept of tiling or how to really make a use of it.
Another one is PyTyle, it’s used on top of non-tiling WM, an addon. Ten-minute with it, I guess.
Before I am going to get into that, there are some terms have to be explained first. If you are familiar with those, then skip this subsection.
Client is a window (program), something you spawn with, say dmenu or your favorite program launcher or you keybind for a special program in dwm. It stays in its own cell in dwm. A client must be tagged with a least one tag. By default, it will be currently viewed tag.
A view can show multi-tag at the same time, and the clients tagged with those tags will be presented with selected layout. The default available layouts, in v5.6.1, are tiling, floating, and monocle. Layout is independent from view, that is changing view doesn’t cause layout change, vice versa.
One monitor can only have one view, but previous view can be brought back.
The default tag list is 1 2 3 4 5 6 7 8 9, but I’ve changed it to 1 2 3 q w e a s d. Notice where they are located on keyboard? They are in 3x3 square shape, well, sort of.
The first three 1 2 3 is used as if they are workspace, I name them workspace tags. I compose, grope, or tag clients with them. When a client is tagged with them, they have already been tagged with only one of q w e a s d, which I call them client tags.
In my rules, please see my configuration, programs I used to use are tagged with client tags. Those programs will always be spawned with generally only one of client tag, but none of workspace tags. For those are not listed in rules, they are spawned with currently viewed tag, and that’s reason I always make sure my currently viewed tag is one of 1 2 3. That way, I won’t have unwanted program being tagged with client tags.
Once a program spawned, I can bring one of client tags to currently viewed tag by pressing ModKey+Ctrl+Tag, then tag the program I need to current workspace tag and turn off the client tag. Or I can just switch to that client tag and tag that program, then switch back.
Most of time, my tag 1 has Firefox, terminal, and video player; tag 2 has the same Firefox and KeepNote. When I need to code, I stay at tag 1; when I need to check up my notes, I switch to tag 2. If the space isn’t the issue, I just bring tag 2 to current view, so I can see all programs tagged with 1 and 2.
However, I do not always stick with these workspace tags. Some of programs I use in client tag, e.g. GIMP. If needed I can temporarily bring the tag with GIMP, then turn off after I am done. Since I keep GIMP in its own client tag, I don’t need to worry that I would bring other programs with it. That’s why I decide to categorize program into their own client tags.
There is plenty of ways to use dwm, it depends how you like to do, no strict rules tell how you should use tags and view. You can even have only one tag, if you really like that, then enjoy tiling.
My Linux distro is Gentoo. For your convenience, you can enable savedconfig USE flag and you will have a default configuration file being initialized at /etc/portage/savedconfig/x11-wm/dwm-VERSION and being pulled from that path when emerge.
When use emerge to install dwm, there is a major drawback, the configuration file can only be edited by root only and installed system-wide and single-configuration. If you are a single user, that doesn’t matter; if not, you will need to manually install dwm at your own home. I am just lazy, so I use emerge and don’t even bother to edit keyword file so I can use latest version.
If you need to include additional code as I do in my configuration, you put the source files at same path where dwm-VERSION at and use full path to include. Be sure to check out these patches, you might find some useful, such as new layouts.
Since you need to recompile for new configuration, that means you need to re-emerge in order to recompile. So, right now I have 99 merges history for dwm package and total merge record is 4942, which means 2% is dwm.
It’s a useless feature for me, because it’s monochrome (there is a patch to improve, I believe) and I already have a better and working dzen system monitor. I reposition dzen to cover the status text.
My first trouble is program with full-screen mode, e.g. MPlayer, Flash, etc. When you enable the mode, you would see a portion of that program and you are sure the program does switch to full-screen, just other program will cover the full-screen’d program.
The solution is simple: 1) make the program floating, then enable the mode; or 2) switch to monocle layout, then enable the mode.
The latter method has little issue, but I wouldn’t call it. The dwm bar stays on top of full-screen’d program. I kind of like that since I can still read my dzen system monitor.
Before I felt I need to use tiling WM, I always couldn’t figure out why you want to split your screen for small areas. I have a 1680x1050 screen and I still didn’t want to split it. But now I feel the program’s window size isn’t always affecting your working performance, it would but not entirely. In fact, split might even help the performance because you can read the reference data or whatever stuff you need alongside. You don’t need to press Alt+Tab< twice just to get the information you need.
But! (There is always a but.) It might also be reducing your performance, because you can have a video playing and that would distract you. Just for the record, I have put three on at once and I hardly type anything on my keyboard.