A peculiarity of the X Window System: Windows all the way down

Original Article ↗ Hacker News Discussion ↗

Graphical user interfaces from X11 to Microsoft Windows and classic Mac OS have long treated nearly every on-screen element—buttons, text boxes, title bars—as a kind of “window” or view, each with its own coordinates, events, and drawing context. Commenters compare how different systems implement this hierarchy (native vs “windowless” controls, client- vs server-side decorations, global handle limits, and input grabbing) and how those choices affect performance, skinning, remote display, and accessibility. The overall theme is that this window-all-the-way-down model is both historically common and conceptually elegant, but it has had to evolve or be partially abandoned as UIs became richer and more complex.

Window-as-universal-primitive

  • Many GUI systems make “everything a window/view”: X, Microsoft Windows (HWND), GTK, Qt, classic Smalltalk views, and to some extent classic Mac (windows plus lighter-weight controls).
  • Developers note this often “falls out naturally” when implementing a GUI: everything has position, bounds, drawing, and children, so “window all the way down” is a common architecture, not unique to X.
  • Some argue for separating concepts (e.g., windows vs controls) even if they share implementation, to keep the mental model cleaner.

Performance, Resources, and Windowless Controls

  • Older systems used many real windows for controls without major performance issues, but hit resource limits (16‑bit GDI/USER heaps, max handle counts).
  • As UIs became richer (browsers, skinned apps, transparency, complex imaging), per-control windows became too heavy; this motivated “windowless controls” and Qt “alien widgets”.
  • Even modern toolkits like Qt make QWidget-heavy lists slow; custom drawing plus event handling for list items scales better.
  • On Windows, GDI used to draw directly to VRAM; with the Desktop Window Manager, windows are now composited textures, closer to X’s modern compositing story.

Client vs Non-client Areas and Decorations

  • Classic Windows distinguishes client and non-client areas (title bar, borders, buttons), each with separate messages; apps usually let defaults handle non-client.
  • OS/2 Presentation Manager treated everything, including the client area, as child windows, simplifying the model at some potential cost in speed.
  • Non-client handling helps keep window movement/closing responsive even when apps are busy or hung; some compare this favorably to client-side decorations on Linux/Wayland, where frozen apps can be harder to manage.
  • There is ongoing disagreement over client-side decorations: some value consistency via server-side frames; others note that apps designed for CSD (e.g., some Linux apps) look better that way.

X Client/Server Model and Terminology

  • Several comments defend X’s “server” being the display system and “clients” being apps: it’s analogous to file/print/database servers mediating access to a resource.
  • Confusion mostly stems from 1990s “client–server computing” marketing and user-centric mental models where “my local machine is the client.”
  • People emphasize that X’s terminology matches networking norms once explained.

Input Capture and Interaction Quirks

  • XGrabPointer/XGrabKeyboard route events to a specific window regardless of pointer focus, enabling features like cascading menus and robust drag behaviors.
  • Similar mechanisms exist elsewhere (e.g., mouse capture on Windows); without them, drags that cross window boundaries would misbehave.
  • Scroll-wheel behavior differs across systems and eras: some always scroll the window under the cursor, others historically required explicit focus; Windows added “scroll inactive windows” relatively late.

Embedding Windows and Composition

  • XEmbed leverages “everything is a window” so one app can parent another’s window (e.g., tabbed containers, embeddable browsers, audio plugins).
  • Win32 can technically reparent top-level windows across processes but suffers performance and complexity issues (thread/context switches, input queues).
  • Some modern components (e.g., out-of-process web views) blur this boundary via more complex plumbing; how this maps to Wayland is viewed as uncertain.

Skinning, Theming, and UI Consistency

  • Windows native controls were hard to skin, prompting custom-drawn UIs and third-party skinning libraries, especially around the XP era.
  • This led to many “XP-like but wrong” UIs that visually mimicked system themes without fidelity to behavior or metrics.
  • On classic Mac, heavily non-native UIs existed but were often frowned upon by users, seen as exceptions rather than the norm.
  • There’s tension between giving apps freedom to draw everything and preserving a consistent, accessible desktop look and behavior.

Historical Toolkits and Nostalgia

  • X is remembered as elegant for its time, especially for network transparency, but early toolkits (e.g., Motif) were painful to use.
  • Newer toolkits like GTK and Tk felt more approachable; others fondly recall XView’s varargs-heavy C API.
  • Several note that the “many small windows” style is now relatively obscure knowledge among modern developers, even though the underlying ideas live on in DOMs and MVC-style view hierarchies.