A lot of people when they move into linux will learn of the magic of tiling window managers.

Generally, they are curious, and some find it as a waste of time, others die by it. And people will even wonder why in the hell someone would take the time to configure one of these things.

However, I’m not here to debate whether or not it’s a waste of time, or if it’s worth it. I’m here to help out people who have heard of dwm and want to try it out. Whether you’ve heard it from a friend, a youtuber, a random, or whomever, people at first find dwm as a scary thing that’s IMPOSSIBLE to configure.

But fret not! For your neighborhood suckless shill is here to help!

Prerequisites

Before you start going ham on the configuring/ricing, this isn’t your average joe i3, Hyprland, or whatever. You’ve probably heard that dwm is a “compile from source” configuration, and this just means that every change you’re going to make has to be compiled all over again.

“Woah, woah, woah!” you might be saying. “Compile? Like C code? H4x0r like stuff?”

Yep, that’s the ticket! But don’t let it scare you off. It’s simpler than it sounds. Think of it like baking a cake. You have a recipe (config.h), you mix your ingredients (the source code and your changes), and then you bake it (make). Each time you want a different flavor (a new feature or keybinding), you tweak the recipe and bake it again. You will need to kill dwm and re-run it again since the binary that runs is loaded in memory, it doesn’t change in real time.

A common misconception is an over exaggeration on how tedious the reconfiguration is. Whilst it can be a bit annoying, especially in the beginning when you are getting it tailored towards your preferences, it’s definitely overblown. See, once you have a working system, there isn’t a need to keep on configuring onwards, a necessary process I would say.

So, what do you actually need?

A C Compiler:

Most likely, you’ll want gcc. It’s the most common C compiler everyone gets.

If you’re on a Debian-based system (like Mint), you can usually get this and other essential tools by installing build-essential.

$ sudo apt install build-essential

For Arch users (for the “I use Arch btw” furries):

$ sudo pacman -S base-devel

And for Fedora folks:

$ sudo dnf group install "Development Tools" "Development Libraries"

Make:

This is a build automation tool that will, well, “make” dwm for you. It usually comes with the build-essential or base-devel packages.

LibX11 development files:

DWM interacts with the X Window System, so you’ll need the development headers for it. Often called something like libx11-dev or libX11-devel.

Debian:

$ sudo apt install libx11-dev libxft-dev libxinerama-dev

Arch:

$ sudo pacman -S libx11 libxft libxinerama

Fedora:

$ sudo dnf install libX11-devel libXft-devel libXinerama-devel

(Note: libxft-dev is for font rendering and libxinerama-dev is handy for multi-monitor setups, which you’ll probably want later on!)

Got all that? Sweet!

Getting the Goods (The Source Code!)

Alright, let’s grab the dwm source code. The suckless crew hosts their code on their own git server. However I recommend personally to get their official tarball releases (this links to the latest of the time of writing this: 6.5) their page.

1. Save the source code to where you want to keep it. A common spot is something like ~/.config/ or ~/.local/suckless/, just anywhere to hide it out of sight.
2. Unextract it
3. Open your terminal & navigate to that directory (using cd and stuff)

Take a peek. You’ll see a bunch of .c files, a Makefile, and the golden goose: config.def.h.

The Infamous config.h

This is where the magic happens, folks. config.def.h is the default configuration. You’re not supposed to edit this directly. Instead, you copy it to config.h:

$ cp config.def.h config.h

Now, config.h is your personal configuration file. Open it up with your favorite text editor. You’ll see C arrays defining your keys, your tags, your fonts, your colors. It might look a bit intimidating at first, but it’s surprisingly straightforward.

For now, don’t change anything. Let’s just get it built!

The First Bake: Compiling DWM

Still in your dwm directory? Good. Time to compile! This is the part that sounds scary but is usually super simple thanks to the Makefile.

To compile and install it system-wide:

$ sudo make clean install

Or, if you prefer not to install it system-wide immediately yet (which is a good idea for testing):

$ make

If all your prerequisites were met, this should complete without errors. You’ll now have a dwm executable file in the directory (and runnable in your terminal if you ran the system wide installation)!

To run dwm, you’ll typically need to configure your .xinitrc file to launch it. For example, you could add this line to your ~/.xinitrc:

exec dwm

For the people who run a Display Manager which is more likely (i.e gdm, sddm, lightdm, etc.). You’ll need to create a .desktop file. This file basically has the information and stuff for the thing to see and run it. You’ll need to create one in the /usr/share/xsessions/. And here’s an example dwm.desktop for reference:

/usr/share/xsessions/dwm.desktop:

[Destop Entry] 
Encoding=UTF-8
Name=dwm
Comment=Dynamic window manager
Exec=dwm
Icon=dwm
Type=XSession

The default keybinding for the Terminal is Alt+Shift+Return. Any other keybindings can be found in config.h, it shouldn’t be hard to understand the giant struct declaration. Comments left by the suckless team are your friends! Read them!

Uh Oh, It’s Plain! Time for Patches!

“Okay,” you say, “this is cool and all, but it’s a bit… barebones. My buddy’s dwm has gaps, a cool status bar, and fancy tag names!”

Aha! You’ve stumbled upon the next layer of the suckless philosophy: patching.

Instead of bloating the core dwm code with every feature under the sun, the suckless community maintains a collection of patches. These are .diff files that you apply to your source code to add specific functionalities.

Want gaps between windows? There's a patch for that.
Want clickable status bar elements? Patch!
Want windows to swallow terminals? Patch!
Want your bar at the bottom? You guessed it, patch!

This is where the “do it yourself” ethos really shines. You pick and choose exactly what you want. However it might be daunting for some people. And unfortunately, many patches don’t really like to work together. If you want a nice dwm patching experience, I would use this one, he’s the same creator as st-flexipatch and other “flexipatch” series. Basically, all you do is edit the patches.h file and you can basically get all the patches you want without too much hassle.

For those who are the tinkers, continue on…

How to Patch (The Basics)

First of all, you’ll need to download the patch utility if you don’t have it. You can probably guess what it’ll be called when you install it using a package manager. Once you’ve done that here are the general steps:

1. Find a Patch: Head over to the dwm patches page. Find a patch you like. Let’s say you want the autostart patch, which allows you to run commands automatically when dwm starts (I highly reccomend this especially if you’re running from a display manager!).

2. Download the Patch: Download the .diff file for the patch. Save it somewhere, perhaps in a patches subdirectory within your dwm source folder.

3. Apply the Patch: In your dwm source directory, use the patch command:

$ patch -Np1 -i /path/to/patchfile.diff

4. Resolve Conflicts (If Any): Sometimes, patches might conflict, especially if they modify the same lines of code or if you’re applying a patch meant for an older version of dwm. This will result in .rej (rejected) files. You’ll need to manually edit the source files to resolve these conflicts, looking at the .rej files to see what couldn’t be applied. This is the trickiest part, but it gets easier with practice. Start with simple, popular patches.

5. Recompile: After applying a patch (and resolving any conflicts), you need to recompile!

$ sudo make clean install

And that’s the patching dance! It can be a bit fiddly, especially when patches conflict, but it gives you incredible control over your window manager. Also, a quick note! Some patches might change the config.def.h, add these new changes to your config.h since they are default configs for the new patches.

Next Steps & The Suckless Mentality

From here, the world is your oyster:

• Explore config.h: Seriously, dive in. Change your mod key (Alt is default, many prefer the Super/Windows key, just change the MODKEY definition from Mod1Mask to Mod4Mask). Change your fonts, colors, and tag names. Recompile after every change.
• Browse More Patches: Get those gaps (vanitygaps), add a systray, try different layouts (fibonacci, centeredmaster).
• Status Bar: Dwm’s status bar is typically populated by setting the root window’s name. You’ll often use a separate shell script or program (like slstatus or a custom script) that periodically updates this. The autostart patch is great for launching such scripts. You can also decide to change out the bar to something like polybar or something.
• Embrace Simplicity: The core idea of suckless is to keep things simple and understandable. If a patch seems overly complex or breaks things too often, maybe it’s not for you. The beauty is in building your ideal, minimal environment.

Don’t be afraid to break things! If you mess up your config.h or a patch goes horribly wrong, you can always run a patch -R -i file.patch. And for the config.h, the config.def.h will always be there as the default to save you.

It’s a journey, not a race. You’ll learn a bit about C, a bit about how window managers work, and a lot about what you really want from your desktop.

So go forth, compile, patch, and make dwm your own! It’s less about having a flashy setup (though you can certainly make it look nice) and more about having a tool that’s perfectly tailored to you. Less is indeed more, especially when you’re the one deciding what that “less” consists of.

Happy Hacking!

– cowmonk