But drawing is only the beginning. An actual window manager must enforce these borders. When you click at (x=400, y=200), the window manager must answer: which window owns this coordinate? Then it must route that click—not to the screen, not to the graphics driver, but to the specific process that owns that rectangle.
Physically, your monitor is a grid of pixels—millions of tiny lights turning on and off. The graphics card sends a frame buffer: a rectangular array of RGB values. That buffer has no concept of a "window." It has no concept of a "taskbar," a "close button," or a "border." actual window manager
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 . But drawing is only the beginning
This is the first deception we accept: that we are clicking "on" a window. In reality, we are clicking on the window manager's map, and the window manager is whispering to each application, "Psst—someone touched your territory." To understand the gap between "window manager" and "actual window manager," we must discuss the compositor . Then it must route that click—not to the
| System | What You Call It | What It Actually Is | |--------|------------------|----------------------| | Windows 11 | Desktop Window Manager (DWM) | A compositor + policy engine + input router, tightly coupled to the graphics kernel | | macOS | Quartz Compositor (part of WindowServer) | A userspace compositor + event manager + window database | | Linux (GNOME) | Mutter | A Wayland compositor + window manager + input manager | | Linux (KDE) | KWin | The same, but with pluggable window decoration and tiling scripts | | Linux (i3/sway) | i3 or Sway | A tiling window manager that is also a compositor (Sway) or relies on X11 (i3) |