Tiling Window Managers: The Alternative Almost Nobody Considers

Windows were never meant to overlap. At least that was the original idea.

When people thought in the seventies about how a screen could give space to several things at once, nobody pictured a chaos of overlapping rectangles. They pictured partitions. Surfaces that divide themselves the moment something new joins — like tables on which books lie side by side, not stacked atop one another. The earliest windowing systems on Symbolics Lisp Machines, in the Andrew Project at Carnegie Mellon University, even Microsoft Windows 1.0 in 1985: all tile-based. Overlapping windows counted as an option, not the default.

Then overlap prevailed. Apple made it popular with the Macintosh, Microsoft followed, X11 on Unix trailed. The reason was not that overlap worked better — it merely looked more intuitive. You could treat windows like papers on a desk, bring the topmost forward, conceal others. The metaphor was graspable. The efficiency was not. Whoever wanted to see something concealed first had to summon it forward. Whoever wanted to survey several things at once had to arrange them by hand. The price of the metaphor was constant manual labour — a price nobody questioned anymore, because there seemed to be no alternative.

Today, anyone running a Linux desktop typically chooses between two major desktop environments: GNOME and KDE Plasma. Both are excellent. Both are floating. Both organise windows according to the paradigm popularised in 1984. And almost nobody asks whether the paradigm holds.

What tiling actually is

Tiling window managers arrange windows not overlapping but tiled. Each new window receives a rectangular area of the screen; existing windows shrink to make room. Nothing is concealed. Every pixel works.

Two sub-categories exist. Manual tiling — as in i3 — demands that you actively split windows into containers; the manager distributes the space accordingly. Dynamic tiling — as in dwm, AwesomeWM or xmonad — computes the layout automatically by an algorithm: master-stack, spiral, grid, whatever. You open a window, the manager sorts. You close one, the rest fill the gap.

The result does not resemble a desk. It resembles a dashboard. And it changes how you work with the machine.

The dominance of floating

Let us speak about the present. GNOME and KDE Plasma dominate the Linux desktop. Both deliver complete desktop environments: panel, app menu, notifications, file manager, settings, themes, display management, session management. They are fully provisioned. Whoever installs them has a working desktop — not a building block from which to cobble one together.

That is no flaw. It is the reason most people stay. A desktop environment is infrastructure. It is meant to work, not to be explored. Most users — even those who chose Linux out of conviction — lack appetite for treating a window manager as a perpetual project.

The distributions do their part. Fedora, Ubuntu, openSUSE, Arch — all ship a floating environment by default. Tiling window managers exist in the repositories, but they sit behind a deliberate decision: you must seek them out, install them, configure them. Nobody stumbles upon i3 by accident. Whoever discovers it has either gone looking — or met someone who uses it.

And here the paradox begins. The same community that compares distributions, debates init systems, fights package formats and wages editor holy wars — the community that champions choice as a value — treats the choice of window paradigm as though only one existed. Yet an alternative exists that is at least as rigorous as anything else distinguishing Linux. It is called tiling. And it leads a shadow existence.

What tiling window managers offer

The advantages are not romantic. They are mechanical.

Keyboard-centred operation. In a tiling window manager you navigate primarily by keyboard. Modes, focus switches, splitting creation, workspace jumps — all key sequences, no mouse travel. Whoever sits eight hours a day at a machine and spends two of them dragging windows wastes time. Sounds marginal. Adds up.

Full surface utilisation. Floating layouts overlap. Overlap means part of the content is hidden — and that you must actively dig to reveal it. Tiling shows everything open simultaneously. On an ultrawide monitor six terminal windows, a browser and a chat sit visibly side by side — without an Alt-Tab olympiad.

Scriptable configuration. i3, sway, Hyprland, AwesomeWM: all configurations are text files. AwesomeWM goes further — its configuration is Lua code. Whoever wishes can generate workspaces dynamically, route windows to particular surfaces by title, switch layouts programmatically. Dotfiles become reproducible. A setup can be committed, versioned, cloned onto a second machine. That is ops thinking applied to the desktop.

Minimal footprint. dwm occupies under two megabytes resident. sway, Hyprland, i3 — all markedly lighter than a full desktop environment. On ageing hardware, on thin clients, on machines doing mostly terminal work, that is no luxury — it is relevant headroom.

Flow over fragmentation. Whoever works in terminals, editors, browsers and documentation simultaneously normally juggles windows. Tiling turns juggling into the steady state: everything visible, reachable, uncovered. Mental context-switching drops.

A morning compared

Consider a typical morning. An administrator walks into the office, coffee in hand, and the machine awaits.

In the floating world: open the launcher, click the terminal — it appears centred, concealing everything. Drag a corner, shove it aside. Open a browser, squeeze it next to the terminal, it overlaps. Bring up the log viewer, another window that fits nowhere properly. After ten minutes of Alt-Tab hunting you have six windows, three half-covered, and you have moved the mouse more than the keyboard.

In the tiling world: Mod+Enter opens a terminal — left half, automatic. Mod+Enter again — right half, split. Browser on workspace 2, Mod+2, there it is, full-pane. Logs on workspace 3, monitoring on 4, wiki on 5. Six workspaces, each plainly assigned, reached over number keys. Hands never leave the home row. After ten minutes you hold the same overview — without having shifted a single window.

The difference seems slight in isolation. It compounds across eight hours, five days a week, year after year. Whoever has worked in this rhythm once regards reaching for the mouse as an interruption — not a tool.

The landscape

The tiling-WM landscape is not homogeneous. A digest of the relevant ones:

i3. The classic. Since 2009, maintained by Michael Stapelberg and the community. Manual tiling, excellently documented, predictable. Whoever learns i3 tends to keep it. The gold standard for newcomers.

sway. i3 for Wayland. Configuration-compatible, drop-in replacement. Whoever wants to migrate from i3 to Wayland finds the direct path here.

Hyprland. The newcomer. Wayland-native, GPU-accelerated, animated, polished. Fast iteration, occasionally breaking changes between releases. Whoever prioritises modernity over stability is in the right place. The community is large, the energy high, the edges still rough.

AwesomeWM. Dynamic tiling, Lua-scriptable, extremely flexible. Whoever prefers to programme rather than configure finds their playground here. The learning curve is steeper, the possibilities boundless.

dwm. From the suckless project. Minimalist, C source code as configuration, dynamic tiling. Whoever values philosophical purity — here. No config file; you patch the source.

bspwm. Binary space partitioning. Windows are recursively split into halves. Elegant concept, consistently executed.

xmonad. Haskell-configured. For those who want functional purity carried all the way into the window manager.

Still noteworthy: herbstluftwm — manual tiling, configurable via a command-line tool at runtime — and river, a rising Wayland project with dynamic layout.

None of these solutions is wrong. They differ in philosophy, configuration method and maturity. But they share one trait: they presuppose that you engage with them.

The honest barriers

Tiling window managers are not for everyone. Concealing that amounts to evangelism, not counsel.

Learning curve. The first days are awkward. You must learn key bindings, build a mental model of container hierarchy, restructure workflows. Whoever floated for decades reaches reflexively for the mouse — and in a tiling setup it is often useless or counterproductive. It passes, but not instantly.

Integration. A desktop environment supplies polkit, notifications, tray, lock screen, display management, accessibility, input methods, theme consistency. A bare tiling window manager supplies: window management. Everything else you assemble yourself. Wayland has improved much, but the effort remains real. Whoever wants a fully provisioned experience does not get it out of the box.

Maintenance. Dotfiles demand upkeep. Upgrades can break configurations — particularly with fast-iterating projects like Hyprland. Whoever builds a setup once and then leaves it untouched for years may freeze. Whoever tracks upstream invests periodically.

Sparse defaults. Tiling WMs ship austere presets. Fine if you think minimally. Less fine if you expected a finished experience. Beauty emerges through configuration — and configuration is labour.

Ecosystem fractures. Wayland cracked the X11 universe. Some tiling WMs are Wayland-native (sway, Hyprland, river), others remain X11-only (i3, awesome, bspwm, xmonad, dwm). Whoever runs a mixed workflow must check compatibility. XWayland helps but is not foolproof.

Dotfiles: from liability to asset

Dotfile maintenance was named above as a barrier — and it is one, as long as you tend it alone. A single user nursing their own configuration answers to nobody but themselves. Yet the moment more than one machine enters the picture, the presumed weakness becomes the decisive advantage.

Ansible — or comparable templating tools — can hold dotfiles as Jinja2 templates. An i3 configuration, a sway config, a polybar bar, a shell rc: all templates with variables. Hostname, username, monitor IDs, keyboard layout, colour palette — injected per machine, varied per team. One playbook, one repository, one invocation — and the entire desktop is configured. Not on one machine. On a hundred.

Idempotent. Repeatable. Version-controlled. The same playbook runs on the developer laptop, the rack server, the thin client in the conference room — and produces the correct configuration from the same template each time. The desktop becomes infrastructure as code. Not as a buzzword, but as practice.

Try the same with GNOME. GNOME stores its settings in dconf — a binary database backing GSettings. The interface is gsettings or dconf on the command line, but what lies behind it is not text. You cannot read it, cannot diff it, cannot hold it as a template. Whoever wants to automate GNOME settings must export them, wrap them in scripts, reload them via dconf load — a detour through binary data that resists any templating logic. It works, but it remains an alien body in the infrastructure-as-code workflow.

KDE is somewhat more approachable in this regard — many settings live as INI-like text files — yet consistency is patchy. Some values migrate into plasmarc databases, others into rc files, and the structure shifts between major versions. Whoever tries to template a KDE setup with Ansible fights a heterogeneous configuration model never designed for automation.

Tiling window managers, by contrast, were built for this. Their configuration is text from the outset, a single file from the outset, deterministic from the outset. No database, no binary format, no hidden state. A template generating an i3 config is as natural as a template generating an nginx.conf. The tools fit because the material fits.

For teams this means: an administrator defines a tiling setup — workspaces, key bindings, colours, autostart — and deploys it via Ansible to every machine. New colleagues get the same desktop on day one. Broken machines are rebuilt and converge to the desired state. An audit asks: how is the desktop configured? The answer lies in the Git repository. Not in a binary database that first has to be dumped.

That is no cosmetic argument. It is the difference between a desktop you administer and one that lends itself to administration.

Who benefits

Tiling window managers appeal to a specific sort of user.

Developers working simultaneously in editors, terminals, browsers and documentation. Sysadmins wanting to keep six SSH sessions, logs, monitoring and a wiki open. Data scientists needing notebook, REPL and plot windows alongside. Power users who regard their desktop as a workshop, not a consumption surface.

But also: people who prize reproducibility. Whoever commits dotfiles possesses a desktop that can be destroyed and restored — in seconds, on any machine. That is no toy. It is backup strategy for the workplace.

And people breathing life into aging hardware. A tiling WM on a 2015 ThinkPad runs fluidly where a full desktop environment labours. That is economically and ecologically relevant — devices live longer when software does not grow alongside them.

Conversely: whoever works chiefly in palette-driven graphics programs — image editing, vector illustration, video cutting, CAD — often finds tiling the wrong answer. These tools thrive on freely arranging large canvases, on floating palettes, on overlapping timelines. Forcing them into a rigid grid creates no advantage, only friction. Tiling is no dogma. It is a tool for a particular mode of work — and whoever has a different one should leave it alone.

A question of attitude

Tiling window managers embody values at the core of the open-source movement: transparency, configurability, hackability, reproducibility. The configuration is legible. The behaviour is traceable. Dependencies are minimal. Nobody decides over my desktop except me.

That is the same impulse drawing people to Linux, to self-hosting, to open standards. Just at the desktop — the spot you stare at eight hours daily, and nonetheless question least.

Add to this a culture that tiling-WM users share: the dotfiles community. Configurations are posted publicly, committed, debated — on platforms that amount to forums in their own right. A setup is no private possession but a draft others study, adapt, improve. That is open-source thinking at its smallest scale: transparency not as duty but as a matter of course. Whoever runs a desktop this way runs it not as a consumer but as a co-author.

Whoever picks KDE or GNOME chooses nothing wrong. Both are superb software. But whoever chooses them without ever weighing the alternative makes no choice. They adopt a stock product. And that, for a community debating every other facet of its infrastructure, is remarkable.

What this means for libcom.de

For twenty-five years I have worked with Linux desktops — in single-seat, team and enterprise settings. I know both sides: the rounded completeness of a desktop environment and the puristic rigour of a tiling setup. Both have their justification. The question is not which is better. The question is which is better for whom.

Whoever comes to me gets no standard recommendation. They get an analysis: How do you work? Which applications, which displays, which workflows? Where are dependencies forcing a particular setup? Then we plan — staged, documented, reversible. Whoever wants to trial tiling needs no leap into cold water. You can test, pilot, evaluate. And if it does not fit, you return — without loss.

If you wonder whether a tiling window manager suits you or your team, or simply want an honest assessment of your current desktop setup: write to contact@libcom.de. We make an honest inventory. Without sales pressure. With a view to what lasts long-term.

Windows were not meant to overlap. That was the original idea. Perhaps it is time to weigh it again.