The Perfect Window Manager

Over the past 10 years, I have tried off and on to stick to a single tiling window manager, i3wm. It has never really stuck on with my workflow: One of the biggest problems that I have faced is that while i3 solves one major problem (efficient screen space usage), it introduces several small ones (audio input/output selection, display selection, and many others). Others who are more proficient with the complete Linux stack face similar issues too. This post is part rant and part solution. The solution is to use PaperWM, a Gnome Shell extension that makes the simplest form of tiling possible: vertical tiling with window resizing. I have been using it for a week, and I am very excited about it, because it combines the battle hardened it will work guarantee of Gnome, with the features of a tiling window manager that I am most interested in.

For those who are used to dragging windows around with their mouse, the merits of a tiling window managers (WM) might be hard to understand. If you don’t have any problems with the way in which you arrange windows on your screen, then you probably don’t need a tiling window manager. The most important issue with my setup that irked me was that I usually have three windows open and a fairly wide 21:9 monitor which can comfortably accommodate them. The default solutions that I was using (Gnome or the default floating WMs on Windows or Mac OS) supported only three modes:

• A floating mode, where windows can be placed wherever one pleases,
• A single window mode, where a single window takes up the whole screen
• A dual window mode, where each window takes up half of the screen

It seems arbitrary to limit the user to a single vertical split. Why do these solutions don’t extend this arbitrary limitation? The obvious one is that there is no need to extend the solution and everyone is fairly happy with one of the above 3 modes. The only other clue that I could find comes from one of the maintainers of Gnome’s window manager: It is not possible to have three column tiling without relying heavily on keyboard shortcuts.

I’m not sure how triple-tiling is expected to work? I don’t think we want a tiling system that only works via half a dozen obscure keyboard shortcuts, so how would mouse-based triple-tiling work without a screen edge?

– Triple-tiling for windows (#966) - GNOME/mutter

This seems like a valid reason to not build it into a window manager which only allows users to interact with it using a mouse. But it can be implemented if only the experts decided they wanted to or their users wanted it. This highlights (what I believe to be) the true nature of open-source: “Anything is possible. But only what the maintainers want is realized.” This is just how it is.

Options for Tiling Window Managers

There are several solutions:

• i3 - improved tiling wm
• awesome window manager
• Sway
• dwm - dynamic window manager
• xmonad - the tiling window manager that rocks

I have used i3 and gone fairly deep into configuring it. I had reached a point where I was using and loving i3 daily. But only for a few days at a stretch. (More on why the streak isn’t longer later.)

I have tried AwesomeWM and Sway. First, Sway: I spent very little time with it. I was not able to launch gnome-terminal in Sway. I don’t know what went wrong, but digging oneself out of a hole where even the Terminal does not start is unthinkable.¹

Next, Awesome. I installed this one too and spent a bit more time in it. One thing that put me off a bit was that the configuration is in Lua. Another thing that surprised me was the concept of “Layouts”. These do not exist in i3. Layouts are predefined structures, that define where windows can be. The operative word here is predefined. i.e. It is not possible to edit them when using the window manager. They must be defined in configuration before one begins using the window manager. This reduces flexibility and forces me to specify how I will want to arrange windows now. I think that’s impossible and I will end up with a system that is less flexible and harder to use than a floating window manager. (One saving grace is that these window managers have a “floating” layout, so at least they are not worse than a floating WM in any situation.)

I have not used the other two. dwm sounds like a non-starter to me because there is no configuration at all; i.e. the configuration is maintained in a C header file config.def.h. It seems strange, unnecessary, and hard to use. I am sure there are good reasons for it. I have wished for well documented configuration in the common markup languages such as YAML, TOML, or JSON; but never have I wished to have configuration within code. Overall, there seems to be little documentation about dwm on its website, and there are no screenshots either. This seems like one of those (unnecessary but) intentional tactics used by projects to keep amateurs away. Though unrelated, I also saw this on Arch Linux’ installation guide, which is quite fitting with Arch’s image as a project for the expert tinkerers:

Boot loader: Choose and install a Linux-capable boot loader.

– Installation guide - ArchWiki

… The link does not tell you how to install a boot loader. I don’t like this attitude much. Software exists to serve people; it does not exist to force people into messing up their computers. (This is the anti-thesis of Debian, which exists to make operating systems open and more usable.)

xmonad is the one window manager that I am intrigued by. I cannot make up my mind over it. On one hand, I would like to try it out because so many people rave about it. On the other hand, it has layouts too, and the configuration is written in Haskell. (It is harder to read Haskell than to write Lua.) I will probably not try it out because I feel like there is no new concept in it, and it would be a solution looking for a problem in my case. I simply do not like this “layouts” thing. Speaking of:

Predefined Layouts

These window managers come with layouts which must be defined before usage begins. For example, one layout that is built into some window managers is “primary-stack” and it looks like this:

----------------------
|      |      |      |
|      |      |      |
|      |      |------|
|      |      |      |
|      |      |      |
|      |      |------|
|      |      |      |
|      |      |      |
----------------------

Here, there are two “primary” windows, which take up the full vertical length, and many windows within the stack, which take up the remaining horizontal width and appear on top of each other. Windows can be moved around freely. Layouts can be cycled through. The layout will stay in this 3 column type layout for the time that we use it though.

There are some basic limitations to this approach. They are best demonstrated by this question:

Does this layout exist? If not, can anyone suggest a good starting point for implementing it?

– Reddit - r/xmonad

The layout that the user is asking for is this one:

--------------------
|         |        |
|         |        |
|         |        |
|         |--------|
|         |        |
|         |  Tabs  |
|         |        |
--------------------

How can I define all the possible layouts that I might ever use until I come across every single thing I would like to do within the window manager?

I know that the retort to this is that these are flexible systems, which can be made to do anything that one wishes for; all one has to do is learn how to configure the system. My problem is with the approach, not the configuration. A system should bring flexibility without configuration. i3wm does this perfectly, by converting window management into a tree:

• There is a root container
• There are non-root containers
• Each containers has one or more windows
• Each container can be in a mode that the user chooses: tiled, tabbed, stacked
• Windows can move freely between containers

This approach makes arranging windows in the layout that the author asks for in the above post trivial. The only learning curve the user has to go through is understanding i3wm’s excellent documentation and setting up keybindings so they know how to make the above choices.

Just Use i3, Then!

If you’ve gotten this far, you have read as I have defended and praised i3. It has a lot of things going for it: The project is very easy to build, has great documentation, and has a configuration file that is in plain text and rather easy to understand. The project brings a window manager, a status bar, and a lock screen, things any window manager needs.

But … the demerits have simply proven to be too many and too much. The breaking point was when I ended up being late for a meeting by several minutes because an external display had decided to turn off (power saving setting), and i3 does not fall back to the internal display of the laptop in this case. (i3 does almost nothing automatically. It is extremely thin.) So, I had to guess my way around a black screen: Use “Mod+Enter” to open a terminal, run a command such as xrandr --output eDP-1 --on to enable the internal display. After this, the audio devices were not switched (they were still sending audio to the display that was disabled, and I could not move that back to the internal audio within pavuctl.) This ended up frustrating me and was the straw that broke the window manager’s back.

The above problem is not new to me: I think most i3 users probably deal with it constantly. Similar things happen if you happen to lock your computer (using i3lock), walk away, and return in an hour or so when the external display has probably disabled itself to conserve power. Either you type something and i3lock’s splash screen comes up, or nothing happens, and you are just stuck: i3 does not reliably do one of these two. This uncertainty in state is hard to live with.

The other problem is with audio devices, their reliable operation, and the ability to switch between them easily. I have been using Linux as a personal device, which means almost no screen sharing or video calling, as most of that happens inside WhatsApp these days. So, Linux sound issues have only plagued me when I am attempting to run a browser within i3 and PulseAudio simply does not detect that an external display which is capable of playing sound is connected. This has also lead me to just kill the i3 session and switch to Gnome.

The final problem is Bluetooth. Once again, when using the computer as a personal device, this is not much of a problem. I have a setup with wired speakers always connected to the computer anyway. When I am outside my home and using the device, I usually go to Gnome because I want to use a Bluetooth audio device. (Audio and Bluetooth? Just give up.) The common solution is to use something like blueman. blueman some times simply does not work and comes up with arbitrary Bluetooth protocol errors which I know do not indicate anything because neither the Bluetooth chip nor the audio device have anything wrong with them. It is just software which is acting up.

I have lived with all this for so long, because I wanted to have three equally sized windows on my screen. This was particularly useful during development: editor, terminal, browser; or during writing: editor, browser, music application; etc. i3 is also flexible enough that I can keep changing the layout to the needs of the moment: If I would like a super small third pane, which only shows the music application, that is possible by going into i3’s resize mode. Switching from 3-column to 2-column or 4-column is trivial. But now that I have started using a Linux computer at work (for the first time in my career), on a day-to-day basis, this unreliability is not going to be tolerable. After setting up a bunch of applications and the layout that I want to work in, having to kill i3 and go to Gnome for a single meeting, and then, to go back to i3, and re-establish what I had set up before … That’s not good enough.

What Next?

This is why I feel like I have found the solution with PaperWM, a Gnome Shell extension. So far, things have been smooth. (Bear in mind that I have only used this extension for 2 weeks.) I will continue to watch out for instability and sincerely hope to find nothing.

PaperWM’s idea is to keep a train of windows, only a few of which are visible at any given point. Windows that go past the screen stay invisible. This is a brilliant solution to simplifying i3, without giving up on the most basic requirements of a tiling window manager. While i3 has to maintain a tree where each node is a windows, PaperWM only needs to maintain a linked list. This reduces the possible operations that are possible significantly! This is how using it usually looks like:

         -- VISIBLE  PORTION --
         ----------------------
|  W1  |  W2  |  W3  |  W4  |  W6  |  W7  |
|      |      |      |      |      |      |
|      |      |      |      |      |      |
|      |      |      |------|      |      |
|      |      |      |  W5  |      |      |
|      |      |      |      |      |      |
|      |      |      |      |      |      |
         ----------------------

Here, I have opened 7 windows. Of these, the windows W1 and W7 are not visible at all. W3, W4, and W5 are completely visible, while only a part of W2 and W6 are visible.

One additional feature is the concept of “useful widths” that one can cycle through using just keyboard shortcuts. Each window’s width can be set to 1/3rd, half, 2/3rd, or anything that the user might want. This is set in configuration. So, the user can decide what is useful to them.²

There will be bugs, I am sure. But even if there is a bug, this is a GNOME Shell extension, written mostly in JavaScript. I have no idea how GNOME extensions are written. But the project feels vastly more approachable, and easy to contribute to, compared to the main i3 codebase (or any of the other tiling window managers.)

Despite all the bad experiences, it seems highly unlikely to me that I will give up on i3. Recently, I have procured a spare laptop, that I intend to use over the next few months to test out a few different distributions of Linux (Manjaro Stable, Fedora, and Nix OS are the ones I have in mind), in order to keep things fresh. While Debian with Gnome and the PaperWM extension will be my daily driver for all activities where I expect things to “just work”, I will keep trying to find a solution that incorporates i3 and has all the peripheral applications that make a tiling window manager fun and easy to use.³