How i3 Differs from wmii and Other Window Managers

i3 was written from scratch after its authors tried to hack and fix wmii, and the differences follow directly from that experience. Compared with wmii, i3 uses libxcb instead of Xlib, replaces wmii's 9P filesystem interface with a lighter IPC interface, arranges windows in a tree rather than columns, and assigns each workspace to a virtual screen so multi-monitor setups (including hot-plugged projectors and rotated monitors) behave correctly. It keeps the minimal-window-manager ethos — simple borders, no bloat — but deliberately does not cap its own size in lines of code when a feature needs the room.

The starting point: lessons from wmii

The i3 project began with a concrete frustration: wanting to hack or fix wmii. Rather than patch around that codebase, the authors agreed on a set of goals and wrote a new tiling window manager. Those goals are the clearest statement of how i3 positions itself against wmii and similar minimal window managers.

Design differences at a glance

The xcb choice is justified on two grounds: a cleaner API and expected speed gains in many situations. The IPC choice is justified as more lightweight than wmii's 9P approach, and because core functionality does not depend on a separate program — which matters most when the system is under load.

What the tree structure changes

Most tiling window managers arrange windows in columns. i3 instead uses a tree structure to arrange windows, which the project describes as enabling more flexible layouts than the column-based approach used by other window managers. If your workflow involves nesting splits — a horizontal pair inside a vertical stack, for instance — that is the structural difference you will feel day to day.

Multi-monitor behavior

i3's stated goal is to implement multi-monitor support correctly by assigning each workspace to a virtual screen. The specific cases called out are attaching and detaching new monitors, such as video projectors, during operation, plus support for rotated monitors. If you move between a laptop panel and an external display regularly, this is the design area to evaluate first.

Modes and IPC

Two features have no counterpart in the wmii description:

• Modes, modeled on vim. You can bind different keys in a resize mode than in the default mode, so destructive or rarely used commands do not need to occupy your main keymap.
• IPC, aimed at other programs. It supports subscribing to certain events and accepting commands.

Who i3 is aimed at

i3 states it is primarily targeted at advanced users and developers. The project also commits to well-readable, well-documented code and to documentation explaining internal workings, so that people who can program but are not familiar with all of X11 internals can still follow why and when things happen. That documentation goal is itself a differentiator from window managers you are expected to read purely as source.

Trade-offs to weigh

• Minimalism with an escape hatch. i3 keeps the usual minimal-window-manager stance — no bloat, no fancy decoration beyond simple borders — but explicitly refuses to enforce limits such as a maximum number of source lines. If a feature needs more code, it gets more code.
• Stability over new features. The project says it is generally happy with the feature set and now focuses on fixing bugs and maintaining stability; new features are considered only when the benefit justifies them. If you need a rapidly expanding feature list, that is a mismatch.
• Licensing and platforms. i3 is Free and Open Source Software under the BSD license, targeting GNU/Linux and BSD operating systems.

Practical next step

To judge the differences yourself rather than from a feature table, the project points to three entry points on i3wm.org: watch the screencast, read the User's Guide, and install i3. The current version listed there is 4.25.1. Running it against your own monitor arrangement and keybinding habits will tell you more about the tree layout and mode system than any comparison can.