Actual Window Manager |top| May 2026

We live surrounded by windows. Not the kind that let in light, but the kind that contain spreadsheets, chat threads, and infinite browser tabs. Every day, you drag, resize, minimize, and close these rectangles. You call the software that enables this magic your .

And when you next sit before your screen, you might glance at the overlapping rectangles and think: None of this is real. But it works anyway. actual window manager

Understanding that it is a construct—a set of compromises between performance, policy, and physics—can make you a better user. When a window lags, you will know: the compositor missed a frame. When focus jumps unexpectedly, you will know: the policy engine made a choice you did not intend. We live surrounded by windows

Who made that cursor appear? Not the terminal emulator—it has no idea your mouse has entered. The window manager did. It noticed the mouse crossing a boundary, sent a WM_MOUSEENTER event (or the Wayland/X11 equivalent), and the terminal responded by changing its cursor. You call the software that enables this magic your

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.

Now move the mouse to a text field in your browser. Click again. This time, the browser receives the click, moves its own cursor, and starts blinking.

Here is the unsettling part: in a composited system, no window ever touches the screen.