My Experience with dwl

I’ve always taken an liking to dwm. For a very short period of time, I actually daily drived it, because I had no other laptops other than my sadly underpowered server, and sucklessware did the job (kind of). My reason for hackintoshing, and preferring macOS in general is the top tier design mixed with your normal everyday UNIX utilities, like good old zsh, cp, and ssh. No bullshit like whatever the fuck PowerShell is.

Why is macOS involved? Because a significant difference between Linux desktop environments and most window managers and macOS is the clean design it has. I used to prefer Linux over anything before I started hackintoshing, with a specific preference of Fedora Linux, but I was using Windows 11 at the time. My oomf convinced me to hackintosh and, I had (almost) never looked back. During that time, I was also experimenting with Chimera Linux, Arch Linux, and Arkane Linux, but I just saw these as testing operating systems because there were no good GUIs for Linux. However, this has (again, almost) changed when I had heard of dwl, a Wayland reimplementation of the dwm we know and love.

I figured that dwl would be worth a shot, so I set up a Arch Linux install, and got to work on installing my second current hyperfixation, the CachyOS kernel. The CachyOS kernel interests me because they bring light to the x86_64-v3 and x86_64-v4 and Zen 4+ processors. These are all apparently highly slept on improvements that the mainline Linux kernel doesn’t use to it’s advantage, and the CachyOS kernels seek to rectify this.

Back to the topic, what I really do not like about dwm is how if you want a new feature, you must apply a patch to it against your local copy of it’s souce code. dwm is meant to be dead simple, and the source code is minimal so that these patches can be applied easier, but one thing doesn’t change, you can slowly get screwed when applying patches, until it just doesn’t work. What we need is an xcaddy approach. A builder script that can take these modifications, apply them, compile dwm, and you have a low effort dwm setup. I always try to recommend the xcaddy approach for some projects, but some might just be fucking hell to maintain, maybe because the program is fragile, or this approach was added later in time.

dwl is no different, and I had to limit my patchset to just three patches: bar, bar-systray, and autostart (which doesn’t even work). I’m completely fine with this, knowing that this may be a suckless tactic to prevent feature bloating in dwm/dwl. I don’t agree with suckless at all, but dwm is the only thing I like from it. Later on, I heard of quilt, which makes managing these patches more easier, but after actually using it to apply patches, I realized that it was a whole lot of nothing, which led me to downsize my patches.

After applying these patches, I realized that we now have access to real screenshot tools like grim and slurp, and more wlroots utilities. Big win! I was also starting to remember that the default dwm keyboard shortcuts were kind of hard to grasp, so to make things easier on me, I changed my master key to the Windows key, which had no effect. I do not like how resizing the windows works, expecially on laptops (yes, I know I can change this), as it requires holding down a right button. I have a trackpoint so maybe this could have been easier, but I keep forgetting it exists.

So, do I recommend dwm or dwl for daily use? Maybe? Probably if you always use a mouse and you’re good with learning curves. Even though I had my setbacks, I would really like to work with this again.

Two days later, I am trying to finally fix my dwl setup… by (mostly) manually patching. I applied the bar patch automatically, and now I have applied autostart and vanitygaps manually. If this doesn’t work, something bad will happen, which didn’t.

Apparently, this built and ran without a hitch, but I didn’t add bar-systray due to the size of the patchset.