Ok, so last time I wrote part one of my mini series of how I switched from XMonad to dwm. Following today is – and what else could it be – part two. As promised, this post will explain a bit more in detail how dwm is meant to be extended and what patches I am currently using.
As we all know from XMonad, the configuration file basically just contains a class set up to you needs, then get compiled and run to manage your windows. To some extend dwm does that too. However it is written in C99 instead of our beloved Haskell and your config file is just a header file included at compile time. If you ignore all files related to GNU’s make, you will end up with two single files, config.h and dwm.c. From here on, extending dwm can not be easier. Just download a patch from dwm’s patch repository or your favorite dwm related web forum, run
patch < mypatch.diff in dwm’s main directory, recompile with a simple
make and you are fine.
Your first patch will be applied as easy as that. But what if you want more then one patch? Usually all patches are diffs to a vanilla version of dwm. So if your first patch changes something fundamental and let’s say changes some data structures, the next patch you try to apply might fail due to being based on an unpatched dwm.c with unchanged data structures. Then, manual patching is the only way to go. Takes a while. Especially if you have 20 more patches to apply…
So now you might ask yourself, what all that hassle about patches and dwm is about. The answer is quite simple. dwm is minimal. Vanilla dwm basically just offers you a floating and a tiling window layout engine, a few keyboard hooks and a basic status bar. You ask for more layouts? Compile them in. You want a coloured status bar and you are unhappy with big ugly borders? Go ahead, edit dwm.c. You need more layout engines? No problem, a patch is the right thing for you.
Currently I am using a patch set based on Andrew Wong’s patches for dwm. The patches he uses are just some patches that made perfectly sense to me successively applied to vanilla dwm v6.0. I extended the patch set by some more and reordered them (–> you want to apply complex patches as late as possible). Let me give you a list of some patches I got and what they do so you get a feeling why patches are that important:
|statuscolours.diff||This one allows me to use colors in my status bar. Eye candy. Love that. However this patch changes how dwm addresses colors, thus if later patches dealing with colors might fail.|
|noborder.diff||removes an ugly padding in the status bar.|
|centredfloating.diff||floating windows should start centered on the screen, not just somewhere.|
|scratchpad.diff||I want a scratchpad. For me
|statusallmon.diff||The statusbar should be displayed on all my monitors, not just the primary one.|
|systray.diff||Adds a systray to dwm’s status bar. Not really a must-have, but always a nice-to-have.|
|morelayouts.diff||Adds layouts I want to use. Will explain them later on.|
|singletagset.diff||One tagset for all screens. Usually each screen gets it’s own tagset, so you can have “Tag 1” on one screen and on another screen. This screw my mind. It might be useful on the long run but for now it’s just orthogonal to what I am used to that I had to change it.|
|cyclelayouts.diff||I want to be able to cycle through my layouts be pressing one key.|
So, as you can see, really basic things, like adding colors to your status bar might change your dwm.c in a way, that further patches can not be applied automatically. Ok, even this sounds really terrible, it’s not that big of a deal. Most patches are just a few lines and if you applied them once to your dwm.c, you won’t need to touch them again. And hell, we know that from XMonad. You just have to spend time configuring your window manager, but your reward will be enormous…
Ok, before I finally close, here is the layouts I added:
The first layout is pretty straight forward, one master area (1) and a lot of child areas. I added a patch to quickly jump between the child windows and the master window using
<MOD4>+<TAB>/<ENTER>. bstack is just the same, but rotated by 90°. The weighted tile layout tries to be a bit smarter than the simple tile layout. As soon as you have a lot of windows opened, the child windows become pretty small. To avoid that, weighted layout cuts down the height of the master area, freeing some space to put some children windows there. This was my favorite layout on XMonad, so wanted that on dwm, too. However I couldn’t find a decent patch for that and had to code it myself. The last layout follows the Fibonacci rules. Each area is twice as big as its successor. This is pretty nice if you want two windows immediately accessible and the others are just there for a quick look-up, maybe something like running htop.
Ok, that’s what I have for you today. The next post on my mini series about dwm will be about my workflow of how I manage my patch set and a brief description of my status bar setup.