It began four years ago when I switched from XP to Ubuntu. It happened again two years ago when I migrated from Ubuntu to Arch. It repeated a year ago when I ditched KDE in favor of Openbox. Now, after twelve whole months of relative calm in the 1049088px digital utopia I had established using Openbox, XFCE4 Panel, Conky and a dozen cronjobs, a newer, more esoteric succubus is here to lure me away from my virtual Shangri-La. In just two weeks, it has already made me succumb to it enigmatic charms. I feel nauseated when faced with conventional floating window managers now, and make a mental note to sacrifice a baby in my dreams for each pixel I see wasted on petty trivialities like taskbars, titlebars, system trays, minimize buttons, maximize buttons, close buttons and other pointless doodads.
What is a tiling window manager (WM) anyway?
Let’s start with what a window manager is first. It is, as the name implies, a piece of software that manages all your open windows, nothing less nothing more. Whenever you perform an action on a particular window, like move, resize, minimize, maximize or close, you are interacting with a WM. Every OS running a GUI has a WM running too. Of course, presenting an end-user with just a bunch of windows to move around isn’t considered nice manners. Hence WMs are often relegated to being just another process in the system started alongside a myriad others to provide a nice and coherent and, not to mention, bloated experience to the user.
It shouldn’t come as a surprise that there is variety in WMs too. The ones that most people are used to, courtesy to them being default in Windows, GNOME, KDE and Mac alike, are called floating WMs. The title window “manager” is outright misleading here, since the actual window management is left to you, the user. It is you who has to manually move the window to desired position and resize it to the right size. The WM only remembers the position of the window and controls placement and ordering of newly opened windows. This works fine so long as you work solely with maximised windows. But try viewing more than one window side by side and the inherent shortcoming of the floating approach shines through.
As if moving and resizing to get the windows to fit without overlapping critical parts of each other wasn’t enough, you are forced to do it again for a newly opened window. And again for each new window you open! To add smelly icing to the crumbling cake, try closing a window now and scratch your sorry ass trying to fathom what good that gaping hole, about the same size as the one in your underwear, left on your desktop offering the world a peek at the aubergine panties of Jenna Jameson wallpaper, is for.
Enter Tiling WMs.
These WMs take a totally different approach to managing windows, in the sense that all windows belong to the same 2D plane. Basically, they abandon the faux-3D illusion of floating WMs (in which windows can overlap each other) and respect the fact that 2D surfaces (your monitor, in case you happen to be thinking about babies overrun by bulldozers) aren’t good for representing 3D.So, in tiling WMs, windows never overlap each other. Think about it. Most of the frustration of using a floating WM arises from the fact that non-maximised windows can – and will – overlap each other, forcing you to go through the resize-move-open-resize-move-close-resize-move-rinse-repeat rigmarole. These problem just doesn’t exist in tiling WMs.
This simpler mode of representing non-overlapping windows in one plane has an added benefit that each window can now be thought of as simple rectangular subsection of a larger rectangle. But what about those gaping underwear-sized wallpaper-exposing holes that are the bane of floating WMs? In tiling WMs, the holes are themselves guaranteed to be rectangles.And what do you put in a rectangle (besides a baby emerging from a bar soap manufacturing line)? Hint: it starts with a W, ends with a W and is not a wheelbarrow.
Since all windows and holes are rectangles, what is the point of having any holes at all? Why not let a window take the maximum dimensions it can take without overlapping other open windows? This is exactly what tiling WMs do, and is probably their biggest advantage too. They live up to their title of window “manager” in a way more glorious than floating WMs fail to. Not having to worry about rearranging windows each time a new one opens is a huge productivity booster once you have more than a couple open. You may feel a lack of control, what with your currently open windows suddenly moving and shrinking to make way for new one, or expanding to fill a void left by a closed window, at least initially. But trust the WM, it knows it’s job better than you do. You will be astonished to discover how much more effective this can be once you get over the getting-used-to phase.
Did I mention that all tiling WMs can be controlled entirely though the keyboard? Yup, they manage to totally circumvent the need for what is perhaps the most recognizable piece of desktop computing equipment ever – the ubiquitous-as-a-motherfuck – mouse! This ideology of ditching the pointy rodent in favour of its CTP-advancing cousin gels well with other stellar Unix applications like vim, tmux, the CLI itself and the excellent vimperator (or its newer cousin pentadactyl) add-on for Firefox.
DWM on Arch Linux
Which tiling WM you choose is purely a matter of personal preference. I chose dwm because it did the most of what I needed and none of what I didn’t. Here’s the last statement again with a bit more loquacity:
- Weighing in at just under 41kb (compiled binary size), I have seen mere crash dumps of heavyweight programs with size greater than this thing
It’s a joy to configure
- This depends on how well you know C, since the only way to modify any settings is by editing its source code and recompiling. While it may sound like a chore to recompile each time you make one small change, it also offers the freedom to customise in ways that a text-based config file just can’t
It’s fast and lightweight
- “# init 5” will never be a reason to get a much-needed toilet break anymore!
Arch Linux offers a binary package for dwm, but it’s kind of pointless since you need the source code for configuring it. There’s also a couple of PKGBUILDs floating around in the AUR. But being the extraordinary piece of software that dwm is, it is only fitting to run it an extraordinary manner. So, I just have a .dwm directory in my home that contains the dwm source code and makefiles, along with my custom scripts and conky configs to run with dwm.
Configuring dwm is done by editing the config.h file (and, if you are feeling particularly masochistic, the dwm.c file). The file is commented well enough to make editing a trivial matter for people even remotely familiar with C. Note that you need to recompile and restart dwm in order for the changes to take effect. To make the process a bit less painful, first configure dwm to restart instead of exit on quit function is called. Start dwm from within a while loop inside your ~/.xinitrc or whatever script you use to start dwm:
while true; do dwm 1 > ~/dwmlog 2 >& 1 || exit done
Now make a shell alias for compiling dwm:
alias cdwm="pushd ~/.dwm; sudo make clean install; popd"
Replace ~/.dwm with whatever directory your source files are located in.
Now, just run cdwm followed by Mod+Shift+Q (or your custom keybind for quit function) to apply the changes without losing currently open windows.
In case you find that you need some functionality that dwm doesn’t provide, try searching for a patch before messing around with the dwm.c file. Good places to look for patches are:
- Patches on suckless.org site [Though exhaustive, the list here isn’t quite updated. Always google for a more recent patch before getting one from this page. Another friendly dwm hacker might have one up on his github repo.]
- DWM Hackers Unite! Share (or request) dwm patches.
Do browse through the links at the bottom of the dwm site for more dwm foo.
That’s about it! Happy tiling and baby-squashing!