Actual Window Manager May 2026

You move your mouse over a terminal window. You click. A cursor appears.

In the old days (pre-2005, roughly), window managers were literal managers. They told X11 or Win32 GDI where each window should paint itself, and the applications drew directly to the screen. If an application froze, its window froze on screen—ghastly, unresponsive, a zombie rectangle. actual window manager

This is why "actual window manager" is a slippery phrase. The manager of pixels is the compositor. The actual manager of input is the event router. The actual manager of window state (minimized, maximized, tiled) is a policy engine. Most systems glue these into one process, but they remain conceptually distinct. Part III: A Brief Taxonomy of Actualities If we take "actual" to mean "the software component(s) that physically control window positioning, stacking, and input routing on a modern graphical system," we find not one answer but a family of them. You move your mouse over a terminal window

The actual handoff is precise: the window manager routes the event to the correct process based on its internal map. But the map is always slightly out of date. Because your input arrives asynchronously—interrupts, device drivers, kernel queues, compositor scheduling—the window manager must guess which window is actually under the cursor at the moment of click, not when the event was recorded. In the old days (pre-2005, roughly), window managers

But have you ever stopped to ask: what is an actual window manager?