Understanding Tiling WM’s

What exactly is a window manager? While most everyone who boots into a graphical environment uses a window manager of some kind, it’s not something average users tend to spend much time thinking on, if they even know it exists at all.

In the typical deployment, the system or desktop environment developers make various decisions about how to set up and deploy the window manager. The users take what they’re given, on average users typically do not have the time to worry over how windows get drawn to their screen. In contrast to this model, tiling window managers approach from a very different paradigm. Most all are minimalist. Very little is configured or even provided out the box and the user is expected to code whatever new features they need. Sometimes from scratch.

Keep this in mind if you’re thinking about installing a tiling window manager. It tends to take a long time to move from the initial configuration to something that’s usable. Don’t take it on if you’re not ready to spend the time making it yours.

That said, what some many view as a limitation others call a boon. As veteran users of Emacs and vim can attest, there is definite and even measurable value in replacing canned software with highly extensible minimalist applications. Especially when these are applications you personally use every day. It does take a lot of time to get these applications into a usable state, but once you reach that point you have an app that perfectly addresses your specific needs, (as opposed to one that only addresses those needs that the developer can imagine for you).

Window Managers in Desktop Environments

Most Linux users are very familiar with desktop environments, or DE’s. For Fedora Workstation, the default desktop environment is Gnome 3. In the event that you are not a fan of Gnome 3, you might have installed one of the alternative spins, which set your default DE to something like KDE Plasma Desktop, Xfce, Cinnamon, or Mate.

Similar to many systems on Linux, desktop environments are stacks. You have a display manager, like LightDM, that handles the graphical login. You have the display server, like X or Weston, that manages the graphical interface and the window manager.

For example, when you open an application like Firefox, the window manager is what draws the window to the screen. It determines the size of the window when it opens, where it appears on the screen and what display it uses. It sets the title-bar and the content of the title-bar. It defines the minimize, maximize and close buttons, both the graphics and the connection between those buttons and the functions that control what they do.

In a desktop environment, the window manager works best when you don’t notice it’s there. It’s layered into the stack with several other applications and, by design, you are meant to experience the stack as a relatively singular environment.

This is generally not the case in tiling window managers.

Configuration Differences

In considering the differences between a DE window manager and tiling window managers covered in this chapter, among the most obvious points lies in how you configure them.

When you first launch a desktop environment, sometimes you have everything you need right there, but often users need to configure, tweak or adjust the DE from its defaults in order to address their particular needs. Often this amounts to simple adjustments, like positioning the panel or dock, defining auto-start applications, selecting preferred apps to appear in the application menu. Specific configuration for the window manager might include title-bar settings, setting up keyboard shortcuts for common operations to manipulate windows or launch specific apps, (for instance, linking C-t to launching the default terminal), or the name, number and layout of workspaces.

The standard procedure for configuring these settings involves opening a special application that’s usually called System Settings. System Settings gives you a window through which to access and modify more specific settings on your system. For instance, there might be a Display Settings icon in there and clicking into it takes you to an interface for adjusting the resolution on your monitor.

On the back-end, System Settings apps read and write their current state to files that you can typically find somewhere in the ~/.config/ directory. Sometimes these files are stored in plain text, sometimes in binary blobs to improve performance when put to use.

The point is that the user’s primary interface in modifying the desktop environment is through the System Settings.

With tiling window managers, this is not the case. Here, configurations are written in plain text files. Usually the user writes what they want in the file and the WM reads the file when it launches. Sometimes, there’s the extra step of compiling the configuration, especially in cases like XMonad or dwm, where the extension language requires compilation.

The point here is that the user has to actually write the config to get what they want.

In comparison, this difference means that while DE’s are easier to configure, WM’s provide a greater degree of control. Furthermore, WM’s, (as well as any DE that saves its configuration in plain text), also provides a better setup for managing your environment through version control systems like Git or Subversion.

Deployment Models

The type of window manager most often found in desktop environments is called a floating or stacking window manager. It’s called this because you can stack the windows together. That is, allow one window to overlap another. From the above sections, it may seem that a stacking window manager gets used with a desktop environment while a tiling window manager gets used by itself, but this is not the case.

It is true that most stacking window managers used by default in desktop environments are rarely used outside of them, but that’s not the case for separate projects. For instance, there is a stacking WM called OpenBox that you can use either by itself or as an alternative to xfwm in Xfce 4. Similarly, you can use tiling WM’s like awesome or XMonad with desktop environments like Gnome.

Bear in mind, these are non-standard implementations. They require greater attention from the user to get them working and to keep them working between updates.

Killing the Mouse

Where most lower level applications have fairly boring descriptive names, occasionally communities form that encourage a little more whimsy. For instance, awesome WM draws its name from Barney Stinson’s catchphrase in the sitcom How I Met Your Mother. For the authors, the personal favorite name for a tiling WM: Ratpoison.


While Ratpoison is not included or planned for in this chapter, its creator, Shawn Betts, re-implemented many of its features into StumpWM, which we will cover at a later date.

The reason behind the name Ratpoison derives from a common feature of all tiling window managers: the desire to kill the mouse.

Keyboards generally feature around a hundred to a hundred and fifty keys, depending on where you bought it. They also feature three to five modifier keys, (or more), which can dramatically further increase the possible key values. It’s not uncommon for someone who types every day to get their speed up into the range of eighty to hundred-twenty words per minute. Which is great and a wonder of modern engineering, but the thing that probably slows your typing speed down more than anything is when you have to move your hand off the keyboard to do something with the mouse.

Window managers all include some method to configure keyboard shortcuts. Tiling window managers take it a few steps further. Their model is to provide enough of a base system that you can handle all environment level operations without touching the mouse. From opening and moving windows to switching between them. It’s all there ready to configure and provides the infrastructure for much better performance than the cumbersome Alt-Tab standard.

Reducing your need for the mouse speeds up your productivity by tying common actions to muscle memory. Which means, you can jump around windows and trigger operations much faster than you would be able to when navigating by mouse.

Tiling vs. Stacking

Consider the kinds of operations a window manager needs to perform. When you open an application, it needs to determine the dimensions of the window, the position of the window, the title-bar, and so on and then draw all that to the display. When you adjust the window size or move the window, it needs to redraw all of that to display at a high enough speed as for the motion to appear seamless to the human eye.

The central difference between stacking and tiling window managers isn’t so much where they’re used as how they handle these operations. In a stacking WM, it needs to calculate everything every time you move something. In a tiling WM, most of these calculations are pre-set or defined by whatever tiling algorithm you have active, which can translate to better performance.

Dynamic Window Managers

It may seem like there should be a great debate between stacking and tiling window managers, along similar lines to the text editor wars, but this does not appear the case in practice. The probable reason is that most tiling window managers today can more technically be described as dynamic tiling window managers.

Dynamic window managers are tiling window managers with stacking options. That is to say, when using something like QTile, you can either let the windows float, like they would on Gnome 3, or you can turn on tiling to get the maximum use from your screen real estate.

< Prev Next >