Where We Went Wrong with Tiling Window Managers
https://cptlobster.dev/posts/tiling-wms
Related projects: swayconf
I’ve tried quite a few different desktop environments in my years of using Linux. My first experience was with GNOME on Edubuntu 10.04 in a VM (although I was still too young to understand much of what I was doing with a computer, and before that I had mainly used Windows XP), and I spent quite a bit of time on Moksha (a fork of Enlightenment created for Bodhi Linux) on my old personal laptop. In more recent times, I’ve had the (dis)pleasure of using GNOME, a slightly better experience with XFCE on my makerspace’s setups, as well as a brief fling with KDE Plasma when I did my first serious Arch install. However, my heart has always stuck with tiling window managers, and I’ve always found myself going back to something like i3.
Every. Single. Time.
I currently use Sway, a Wayland adaptation of i3, with a heavily customized config that I ported from my original i3 install. Both are lightweight window managers, and you can very easily make them work how you want to (provided that you are willing to put the time into configuring them as such). I tried Hyprland for about a month; after configuring my keybinds to be roughly equivalent to my i3 config I was very pleased with it, but I switched back to Sway because my battery life was much better. I miss some things about Hyprland, including its sensible auto-layout stuff (better than i3/sway’s default mode of stacking everything right next to each other until you say otherwise), and better support for dynamically managing multiple displays. This is important to me, as I have a laptop and switch between using it on its own or docked with external monitors. I can use Kanshi with Sway for dynamic monitor reconfiguration, but that’s a separate application to setup.
I’ve also spent some time using Regolith, a project that takes i3/Sway and builds an entire desktop environment around them. I’ve been using Regolith on my work laptop and Sway (with my custom configs) on my personal, and in using both I’ve found things I like (and hate) about one or the other. I hadn’t thought much about it, but an article from The New Stack (“Regolith Linux Is a Great Introduction to Tiling Window Managers”) caught my attention. This encouraged me to re-examine Regolith, but to consider if it lived up to the expectation. Is it a great introduction to using tiling WMs? I believe that it falls short of expectations, but its shortcomings are a common issue for tiling WMs as a whole.
For this article, I hope to examine some of the new tiling window managers, how they attempt to make the experience simple for new users, and what their individual flaws are. Hopefully, this can be inspiration to create a more “batteries included” project that works for everyone.
What is a tiling window manager?
In short, a tiling window manager usually arranges windows in a tiled layout automatically, rather than letting you move them around randomly. Most use keyboard controls to move and resize windows, rather than having you click and drag windows; some, like Sway and Hyprland, support using the mouse to arrange windows. Additionally, windows are arranged on a set of virtual workspaces; you have a set of windows on one workspace, and can switch to another workspace that has a different set of windows. Traditional floating window managers also have this, but it isn’t quite as obvious or essential. On a tiling window manager, there isn’t really a notion of “minimizing” a window; you would just send it to a different workspace. In my opinion, this makes it harder to lose track of windows.
The jury is out on whether a tiling window manager is more efficient to use than a traditional window manager; for me, once I got used to the keybindings, I found it much quicker to just use the keyboard to arrange things than to fuss with a mouse. It really depends on the user.
Regolith: Great on paper, messy in practice
Regolith’s main selling point is that it provides a tiling window manager experience with the niceties of more fully-featured desktop environments (such as GNOME or KDE). It draws on GNOME for more DE-specific things (the simplest choice for an Ubuntu-based distribution that’s already infected), including session management and default applications. This makes Regolith a relatively simple switch for anyone already familiar with Ubuntu; just add their apt repository, install a few packages, and you’re good to go.
First, the good: It’s easy to use out of the box. Whether you have a fresh install of the Regolith distro or are setting it up on an existing Ubuntu/Debian installation, you have an easy-to-use interface. It presents you with all the most useful keybinds on first login (which for the most part are equivalent to i3’s default keybinds), and you can quickly start launching applications / moving windows around / whatever you want to do. If you need to mess with display settings or whatever, their bundled fork of gnome-settings will let you tweak everything like you would normally in Ubuntu. Also, their custom launcher application Ilia is very nice to use, and I might try to add that to my Sway setup (at least if the Nix flake works).
Now, the bad. I have my opinions on Ubuntu and GNOME (mostly negative), but I will refrain from going on about that for now. Perhaps another post in the future. The main pain point I have with Regolith is around how it handles configuration. I get that they want to try to make it easier for new users, but in my humble opinion, they took the wrong approach and only made the process more convoluted than just using i3 and Sway on their own.
Using the Package Manager? For Configs??
On Regolith’s Configuration docs, much of the underlying configuration is handled by installing and removing packages containing configuration snippets. Some things make sense, like themes, support for utilities such as notifications, ilia, and X11 compositors, but they have key bindings as installable packages. Want to resize a window? Install regolith-wm-resize. Want to use different keybinds for navigating your window manager? Uninstall regolith-wm-navigation. Want to add keybinds for accessing settings pages instantly? Install regolith-i3-gnome. First, this approach has some limitations:
- Since packages are installed globally, this would affect configuration for all users on the same system. This is not ideal for a multi-user environment where other users may not want certain keybinds.
- This locks you into package managers that Regolith actively supports (in this case, apt only), which means that a user on any other system (i.e. Fedora, Arch, NixOS) can’t try out Regolith.
What makes this even more confusing is their method of overriding configuration settings and keybinds (described on the same page). You have to change the file ~/.config/regolith3/Xresources, and set specific keys. For example, to swap your super and alt key, you would use the following in your Xresources:
wm.mod: Mod1
wm.alt: Mod4
Some keybindings cannot be adjusted in this file either. I tried to disable the default suspend keybind (Super+Shift+S) because I usually set that keybind to open screenshot tools (A holdover from my Windows days unfortunately) and it got very annoying to wake up my laptop every time I tried to take a screenshot. This was not an option that I could change in Xresources, and I would need to change system files to adjust that keybind (something I can’t do if I have limited sudo permissions). Further, some keybinds are not controlled from that file, but need to be set in gnome-settings. Therefore, you have three different places you have to go to manage your configuration settings: the package manager, the Xresources file, and gnome-settings. If you read further into the documentation, they also support you writing your own i3 config file snippets (a fourth way to manipulate all this config crap!) and saving them in your .config folder, however then you also have to learn i3’s config syntax (which you would be doing anyways if you switched to a tiling WM with less training wheels).
You probably understand at this point that I’m not too fond of how Regolith handles configuration. However, is this just a Regolith issue, or is it something inherent with tiling WMs as a whole?
Tweaking Configurations Isn’t A Hobby, It’s A Lifestyle
Comparatively, i3’s configuration is typically handled through a very detailed and convoluted config format stored at .config/i3/config. You set up literally everything yourself in there, from startup applications to keybinds to workspaces to status bars. If other applications you rely on (such as i3status or rofi) have their own configurations, you have to manage those files separately as well. A friend of mine once described learning i3 as “a Masters degree in keyboard shortcuts”, but I think it’s more of a degree in configuration file writing. Not only that, tiling window manager configurations are more of a series of commands than a proper configuration format. Considering that you need to set up everything yourself in most tiling window managers, the only way to succeed is to learn the config, love the config, sacrifice all mortal possessions to the config.
In i3’s case, the i3-config-wizard will run at your first launch and give you a default config with all the basic keybinds. In my case, I kept quite a bit of that config intact despite tweaking a bunch of things. Other window managers will sometimes give you less. In Hyprland’s case, they give you enough to launch kitty, a terminal emulator, and to exit the session. Not a lot more than that. If you’re using a different terminal emulator, you first need to jump to a TTY, change the command in the config (or install kitty in your package manager of choice), and then you’ll have a working keybind. I haven’t tried much other window managers to know how their defaults are (Sway’s default config is also rather limited, but because it’s designed to be a Wayland equivalent of i3 you can just run i3-config-wizard as a baseline and work from there).
Therefore, the main issue that turns people away from using tiling window managers is the complexity of setting it up how you want to. I think that a “batteries included” tiling window manager should at least help familiarize you with the configuration along the way, but Regolith only further obfuscates it by adding more layers of complexity (especially with all the package manager stuff).
Omarchy: The “Latest Fad”
In recent times, I have seen a lot of discussion (and controversy)[1] surrounding Omarchy, a “beautiful, modern, and opinionated Linux” distribution. It’s an Arch-based distribution using Hyprland as its window manager, with quite a bit of configuration and default applications supplied.
Fortunately, they don’t stray too far from the usual configuration structure for a tiling window manager; their user guide has information on where certain configurations live and how to edit them. Additionally, some simple configuration is managed via menus configured in Walker, their default application launcher.
However, Omarchy is very opinionated. The default application set includes a lot of specific applications (i.e. 1Password for password management, Dropbox for cloud sync, Spotify for music) that some won’t end up using, as well as some dedicated webapp shortcuts (a couple services made by the group that Omarchy “originated” from) and for some reason dedicated AI shortcuts / installations. Admittedly, most additional applications can be uninstalled easily.
It’s just dotfiles
In essence, Omarchy is just Arch with someone else’s dotfiles. It’s going to be very opinionated because it’s someone’s configuration that they carefully crafted for their own workflows. Either you’ll end up changing it a ton on your own or trying to adjust your own workflow to fit their configuration. Neither solution is ideal.
Admittedly, Omarchy handles it better than Regolith by letting you reconfigure things using the same syntax that Hyprland natively uses. Therefore, you can understand it better yourself if/when you decide to branch off into your own customized setup.
Tiling Extensions for Non-Tiling WMs: They’re All Kinda Bad[2]
Some non-tiling WMs have extensions that allow for tiling layouts, but they are usually low-quality, not well integrated, or heavily limited in features. Pop!OS had a tiling extension when they used GNOME as their desktop environment, but have abandoned it in favor of their new COSMIC Desktop; You can bastardize it onto newer versions of GNOME, but not without some issues. KDE’s built-in tiling is very clunky to use and third-party extensions also don’t allow one to arrange windows easily. Enlightenment has a built-in tiling mode, but it’s very rudimentary and some apps (such as Discord) don’t play nice.
Additionally, in KDE Plasma there is a way to replace the KWin window manager. This only works with an X11 window manager, and is rather hacky to set up. I attempted this previously[3], using i3 as my window manager, but it had a ton of issues that made the setup unusable in many aspects. Needless to say, I would not recommend trying to achieve tiling this way.
What is the inherent problem?
Tiling window managers are complex. This is just a fact. They are designed so that you can mold them in whatever way you want. This is really what Linux as a whole is, it’s intended to give the user maximum control. However, the freedom to configure things is also the barrier to entry; because of how free-form it is, it’s daunting to set things up the way you want; you become overwhelmed by options. In attempting to make configuration less daunting, most existing solutions fall into anti-patterns that dissuade people from experimenting, especially when those anti-patterns completely disrupt the actual configuration process.
Additionally, tiling window managers are usually rather minimalist compared to their traditional non-tiling counterparts (i.e. GNOME, KDE, XFCE, et al.). Those are built as full, cohesive desktop environments with all the bells and whistles included by default. They created a set of applications that are integrated with each other; while more rigid, it’s less work for the end user to do. Compared to most tiling window managers, which expect you to bring your own environment (i.e. display manager, idle management, notification daemon, application launcher, etc., etc.). This lets you achieve the exact environment that you want, but also requires you to know what you want. Most users won’t know that right off the bat, and won’t want to spend hours troubleshooting to discover what additional components they need to bring.
How should we fix this?
As we have seen above, there have been attempts to build a full desktop environment around a tiling window manager, or adapt existing desktop environments to support tiling. I’m going to focus on the former, as extensions won’t be able to give a true tiling experience. There are a couple possible approaches one could take to this:
- The Regolith Approach: Take an existing desktop environment (such as GNOME or KDE) and integrate its components with a tiling window manager. This is probably the least effort, and provides a relatively complete user experience; although this is the most opinionated as it would tie you to a particular desktop environment’s utilities.
- The Omarchy Approach: Provide a well-configured baseline for a tiling WM, giving users the freedom to adjust as desired. This setup provides a lot of flexibility, and can also serve as a better stepping stone towards more customized setups, but isn’t quite as beginner friendly as it relies heavily on altering config files.
- Start Fresh: Build an entirely new desktop environment around an existing tiling WM, or just build a completely new desktop environment with its own integrated tiling WM. This is a lot of work but would ultimately provide the most coherent experience.
No matter which approach you take, keep the following in mind:
- Keep the configuration as close to home as possible. Don’t make sweeping changes to how configuration is handled, such as relying on the package manager to manage configs. This will limit you to specific distributions, which is not ideal. If you can manage configuration using the underlying window manager’s format (or with some sort of overlay that isn’t overly different), this would be a good balance between usability and feature parity.
- Don’t get too opinionated. Sure, you can add some optional features, include some sensible default applications, but maybe adding that AI keybind is a bit too far. If I wanted that I would just bite the bullet and use Windows.
- Have decent mouse support. If you want to introduce users to a tiling window manager, don’t just throw them to the wolves right away with a ton of keybinds. Sway’s mouse support is pretty good if you have titlebars enabled, you can just click and drag windows around by the titlebar (although client-side decorations don’t let you do that).
- Design it for minimal effort after installation. That means include everything you expect in a functional desktop environment; something to launch applications, a status bar with useful information / tools on it, a notification daemon, and a way to configure settings (bonus points if it’s a GUI). Some other nice to haves would include dynamic output management (i.e. remembering where displays belong, especially for connecting a laptop) and a good baseline of graphical tools (such as a file manager, music player, system monitor, etc.).
With these ideas in mind, one could build a more beginner-friendly tiling desktop environment, one which could be a springboard to a more deeply customized environment. This won’t be ideal for everyone, as power users will want to tweak things more to their liking, but this would be a less daunting path for those who don’t want to constantly edit dotfiles.
Most of the criticisms of the Omarchy project are directed towards DHH, the creator of the distribution (as well as Ruby on Rails). These criticisms are primarily for political reasons, which are not relevant to this post; I am analyzing Omarchy solely from a technical perspective. ↩︎
This is based on additional testimony from other friends of mine. I have only tried the Enlightenment tiling extension and my horrifying i3/plasma amalgamation[3:1], but haven’t experimented very far beyond that. ↩︎
I previously attempted this on Arch Linux and created a repository with information. I was going to include dotfiles as needed, but I did not get things working well enough. If I attempt this again, I will likely make a Nix derivation for it and call it a day. For now, my current Sway setup is more than adequate. ↩︎ ↩︎