Hubbry Logo
X window managerX window managerMain
Open search
X window manager
Community hub
X window manager
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
X window manager
X window manager
X window manager
View on Wikipedia
from Wikipedia
The windowing system based on the X11 protocol keeps display server and window manager as separate components.

An X window manager is a window manager that runs on top of the X Window System, a windowing system mainly used on Unix-like systems.

Unlike MacOS Classic, macOS, and Microsoft Windows platforms (excepting Microsoft Windows explorer.exe shell replacements), which have historically provided a vendor-controlled, fixed set of ways to control how windows and panes display on a screen, and how the user may interact with them, window management for the X Window System was deliberately kept separate from the software providing the graphical display. The user can choose between various third-party window managers, which differ from one another in several ways, including:

  • customizability of appearance and functionality:
  • consumption of memory and other system resources
  • degree of integration with a desktop environment, which provides a more complete interface to the operating system, and provides a range of integrated utilities and applications.

How X window managers work

[edit]

When a window manager is running, some kinds of interaction between the X server and its clients are redirected through the window manager. In particular, whenever an attempt to show a new window is made, this request is redirected to the window manager, which decides the initial position of the window. Additionally, most modern window managers are reparenting, which usually leads to a banner being placed at the top of the window and a decorative frame being drawn around the window. These two elements are controlled by the window manager rather than the program. Therefore, when the user clicks or drags these elements, it is the window manager that takes the appropriate actions (such as moving or resizing the window).

Window managers are also responsible for icons. Indeed, icons do not exist at the X Window System core protocol level. When the user requests a window to be iconified, the window manager unmaps it (makes it non-visible) and takes the appropriate actions to show an icon in its place. Most modern window managers do not literally show icons to represent iconified windows anymore. Often, an auxiliary toolbar program will allow access to iconified windows.

While the main aim of a window manager is to manage the windows, many window managers have additional features such as handling mouse clicks in the root window, presenting panes and other visual elements, handling some keystrokes (e.g., Alt-F4 may close a window), deciding which application to run at start-up, etc.

Standardized protocols exist to allow normal clients to communicate with the window manager. The original one is Inter-Client Communication Conventions Manual (ICCCM) but this has been superseded by the Extended Window Manager Hints (EWMH). These protocols allow clients to request titles for windows and icons, check if a window is iconified which might be docked or minimized, and possibly customize windows decorations, what virtual desktop the window occupies.[1] Additional information from the window manager is available through the core protocol including the visibility of windows such as if a window is hidden on a different Virtual desktop, and figuring out the adjustments for the window manager frames.[citation needed]

Types of window managers

[edit]

Stacking window managers

[edit]
Main article: Stacking window manager

A stacking window manager renders the windows one-by-one onto the screen at specific co-ordinates. If one window's area overlaps another, then the window "on top" overwrites part of the other's visible appearance. This results in the appearance familiar to many users in which windows act a little bit like pieces of paper on a desktop, which can be moved around and allowed to overlap.

In contrast to compositing window managers (see below), the lack of separate off-screen buffers can mean increased efficiency, but effects such as translucency are not possible.

Stacking window managers include Amiwm, Blackbox, CTWM, Enlightenment, Fluxbox, FLWM, FVWM, IceWM, MWM, Openbox, TWM and Window Maker.

Tiling window managers

[edit]
Main article: Tiling window manager

A tiling window manager is a window manager with an organization of the screen into mutually non-overlapping frames (hence the name tiling), as opposed to the traditional approach of coordinate-based stacking of objects (windows) that tries to emulate the desk paradigm.

Tiling window managers include awesome, dwm, ion, larswm, ratpoison, Stumpwm, wmii, i3, xmonad, and XWEM.

Compositing window managers

[edit]
Main article: Compositing window manager

A compositing window manager may appear to the user similar to a stacking window manager. However, the individual windows are first rendered in individual buffers, and then their images are composited onto the screen buffer; this two-step process means that visual effects (such as shadows, translucency) can be applied. It also means that compositing window managers are inherently more resource-hungry than an equivalently-powerful stacking window manager. For this reason, some window managers for X do not support compositing by default, such as Openbox.

Historically, the Amiga in 1985, OSX in 2001, Java Looking Glass in 2003, and the Windows Longhorn demo in 2003 (delayed until Vista in 2007) preceded compositing efforts under X11. Compositing window managers for X include:

Compositing support can be added to non-compositing window managers, through the use of compositors such as compton.

Virtual window managers

[edit]

A virtual window manager is a window manager that uses virtual screens, whose resolution can be higher than the resolution of one's monitor/display adapter thus resembling a two dimensional virtual desktop with its viewport. This environment is very useful when one wishes to have a large number of windows open at the same time. A number of virtual window managers have been made, including FVWM, Tvtwm, HaZe[2] and others.

Extensible window managers

[edit]
See also: Category:X window managers extensible by scripting

Some window managers are extensible, or programmable, by user scripts.

In these window managers, users can define new actions or override the default, or reactions to various events, like window size and position changes, window creation and deletion, key and mouse input, timer, etc. They often provide on-the-fly code execution, too.

Some examples of such window managers and the used languages are:

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

X window manager

View on Grokipedia
from Grokipedia
The X window manager is a client program within the that controls the placement, appearance, and behavior of top-level windows, mediating resource allocation such as screen space and enabling users to resize, move, iconify, and manage graphical applications through a defined policy. It operates as an intermediary between application clients and the X server, handling window states (normal, iconic, or withdrawn), geometry requests, input focus, and decorations like title bars and borders, while adhering to inter-client communication conventions to ensure compatibility across diverse implementations. Developed as an integral component of the , which originated in 1984 at MIT's under Robert W. Scheifler and Jim Gettys, window managers evolved from early designs supporting hierarchical, overlapping windows on bitmap displays, building on predecessors like Stanford's W system. The system's asynchronous client-server protocol, stabilized in X11 by September 1987, formalized window management primitives for manual control of top-level windows, including resizing and repositioning, without embedding policy in the core protocol to allow flexibility. Initial window managers like the Window Manager (uwm) handled basic operations in X10 and early X11 releases, but by X11R4 in 1989, (Tab Window Manager) became the standard, introducing features such as title bars, icons, and configurable bindings. Over time, X window managers have diversified into categories including stacking (or floating) managers like , , and , which allow freeform window placement; tiling managers that automatically arrange windows in non-overlapping layouts for efficient space use; and compositing managers like Compiz or , which add such as transparency and animations via extensions like XRender. Many modern ones integrate with desktop environments—such as (using Mutter, a fork of Metacity) or (using )—providing seamless theming and keyboard shortcuts, while standalone options like i3 or Awesome cater to minimalist or advanced users in systems. Despite the rise of alternatives like Wayland, X window managers remain prevalent in legacy and specialized applications, underscoring the enduring relevance of X11's in open-source .

X Window System Fundamentals

Core Architecture

The is a network-transparent, protocol-based designed for displays, allowing applications to render and handle user input across local or remote connections. This architecture separates the display management from the applications, enabling multiple programs to share hardware resources such as monitors, keyboards, and mice without direct access to the underlying devices. The system's design originated from MIT's in 1984 and emphasizes portability across different hardware platforms. Key components include the X server, which runs on the user's machine and handles all input and output operations, including drawing to the screen and processing events from devices like the keyboard and mouse. X clients are the applications that request graphical services from the server, such as creating windows or loading images, but do not directly control the display hardware. The display manager serves as an initial X client that manages user logins and starts sessions, often integrating with desktop environments. Communication between clients and the server occurs via the X protocol, which has been standardized as version 11 (X11) since and defines a stream-based format for requests, replies, events, and errors. This protocol supports by operating over TCP/IP or other reliable octet streams, allowing a client on one machine to display output on a remote server's display. Resources such as fonts, colors, and input devices are managed at the protocol level through specific requests; for instance, fonts are loaded and queried using operations like OpenFont and ListFonts, while colors are allocated via colormaps and graphics contexts. Input devices are handled through event mechanisms, including grabs for keyboards and pointers to control focus and interactions. Window managers function as specialized X clients that intercept and manage window-related requests from other clients, building upon this core protocol foundation.

Client-Server Model

The X Window System employs a client-server architecture where multiple client programs communicate with a single X server responsible for managing display hardware, input devices, and graphical resources. Clients issue requests to the server via the X protocol to create windows, draw graphics, and handle input, while the server executes these requests by rendering output on the screen and dispatching input events back to the appropriate clients. This separation ensures that clients do not directly access hardware, promoting portability and modularity across different platforms. Communication between clients and the server is asynchronous and occurs over a reliable byte stream connection, typically facilitated by libraries such as , which buffer requests for efficient transmission without blocking the client unless explicitly synchronized. Direct interaction between clients is prohibited; all inter-client coordination must route through the server or adhere to defined conventions like and selections. Xlib handles low-level protocol details, allowing developers to focus on application logic while maintaining the asynchronous nature of operations. A key feature of this model is , enabling clients to connect to a remote X server over a network as if it were local, which supports environments. For instance, X applications can be run remotely and displayed locally by forwarding the X protocol over secure channels like SSH, where the SSH client establishes an authenticated tunnel for X connections. In this framework, function as special clients, often termed "root clients," that intercept and manage top-level windows created by other applications. By selecting for substructure redirection events on the root window, the gains authority to reparent application windows—reassigning their parent from the root to a frame window it creates—allowing it to add decorations, enforce sizing and placement policies, and control visibility without altering the core protocol. This reparenting mechanism integrates seamlessly with the client-server model, as the communicates with the server just like any other client.

Role and Functionality

Window Placement and Sizing

Window managers in the are responsible for determining the initial position and of top-level windows created by client applications, ensuring they fit within the screen boundaries and adhere to policies. This involves processing client-provided hints while allowing the manager to override them for usability or aesthetic reasons. Unlike the X server, which handles low-level drawing and event dispatching, the window manager acts as an intermediary to enforce consistent layout behaviors across applications. Placement can occur automatically or manually based on client hints specified in the WM_NORMAL_HINTS property. If the client sets the PPosition or USPosition flags in this property, it indicates a program- or user-specified position, prompting the window manager to honor the requested coordinates (x, y) during initial mapping; otherwise, the manager employs automatic placement algorithms, such as cascading new windows from a starting point or using screen geometry to avoid overlaps. Similarly, for sizing, PSize or USSize flags suggest explicit dimensions, but without them, the manager may default to a standard size or adjust based on window type. These hints are defined in the Inter-Client Communication Conventions (ICCCM), which recommend that managers respect them to avoid conflicts, though overrides are permitted for better . The WM_NORMAL_HINTS property also includes constraints like minimum and maximum widths/heights (min_width, max_width, etc.), increment steps (width_inc, height_inc), and base dimensions (base_width, base_height) to guide resizing behavior. Window managers must enforce these during configuration changes, preventing clients from requesting invalid sizes via ConfigureWindow requests; for instance, a client cannot shrink below the minimum without violating ICCCM guidelines. Additionally, the win_gravity field in WM_NORMAL_HINTS specifies how the client window repositions relative to its frame during resizing or , using values like NorthWestGravity (1) for top-left alignment or CenterGravity (5) for centered placement. Complementing this, the window's bit_gravity attribute, set via CreateWindow, controls content retention on resize—e.g., NorthWestGravity retains the top-left region, while ForgetGravity discards all contents, requiring full redrawing. These gravity mechanisms ensure efficient handling of changes without excessive server traffic. To add decorative elements, window managers typically reparent top-level client windows by creating a new parent frame window, embedding the client as a child, and positioning it accordingly. This frame includes borders for visual separation and titlebars for identification, with the client's requested geometry applying to its undecorated content; the manager adjusts the overall frame size to account for these additions. Reparenting triggers a ReparentNotify event to the client if it selects for structure notifications, allowing adaptation to the new hierarchy. Transient windows, marked by the WM_TRANSIENT_FOR pointing to a parent window (e.g., for dialogs), often receive simplified decorations or automatic placement near the parent to maintain context, as per ICCCM conventions. The initial mapping process begins when a client creates a top-level window using XCreateWindow and sets relevant properties like WM_NORMAL_HINTS, then issues XMapWindow. The X server intercepts this and sends a MapRequest event to the window manager, which evaluates hints, performs reparenting if needed, computes final position and size, and issues its own MapWindow to display the window (or frame). The manager then sends a MapNotify back to the client, signaling successful mapping; clients should wait for Expose or VisibilityNotify events before drawing to avoid artifacts. This sequence ensures coordinated layout without direct client control over final geometry.

User Interface Controls

Window managers in the manage user interface controls by defining policies for input focus, binding user inputs to actions, providing visual decorations, and integrating with session management protocols. These controls enable efficient interaction with multiple windows while adhering to established standards for . Focus models dictate how keyboard and input is directed to specific windows. According to the Inter-Client Communication Conventions Manual (ICCCM), clients declare their preferred input focus model through the WM_HINTS , which includes an input field (True or False) and the presence or absence of the WM_TAKE_FOCUS atom in the WM_PROTOCOLS property, defining four models: No Input (input=False, absent), Passive (input=True, absent), Locally Active (input=True, present), and Globally Active (input=False, present). In the Passive model (input=True, WM_TAKE_FOCUS absent), the window manager handles focus assignment without client involvement, commonly implementing click-to-focus behavior where a user must click on a window or its decorations to activate it. In the No Input model, the client does not interact with focus. The Locally Active model allows the window manager to send a WM_TAKE_FOCUS ClientMessage to the client, which then sets focus using XSetInputFocus with the provided . The Globally Active model enables the client to manage its own focus directly via XSetInputFocus, coordinated by the window manager sending WM_TAKE_FOCUS when appropriate. A widely adopted variant, sloppy focus, modifies focus-follows-mouse by retaining focus on the previous window when the pointer moves to the root window or uncovered desktop areas, avoiding unintended focus shifts to non-interactive regions; this is exemplified in window managers like , where it is configurable as "Sloppy-mouse-focus." User inputs are facilitated through configurable keyboard shortcuts and bindings, which map keys or presses to operations. While no universal standard mandates specific bindings across all window managers, common conventions include for cycling through open s in a most-recently-used order, as implemented in managers like and via their configuration mechanisms. bindings typically allow actions such as raising a on press or dragging to resize, with window managers like defining these through and function bindings in their resource files. Window decorations enhance usability by providing visual cues and interactive elements. Window managers reparent client windows into a decorative frame, adding a titlebar that displays the window's name from the WM_NAME property, which clients set as a string for identification. Standard decorations include buttons in the titlebar for minimizing (iconifying), maximizing, and closing windows; ICCCM compliance requires support for the WM_DELETE_WINDOW client message protocol, enabling clients to handle close requests gracefully instead of forced termination. The Extended Window Manager Hints (EWMH) specification builds on ICCCM by defining properties like _NET_WM_NAME for encoded titles and _NET_WM_STATE atoms (e.g., _NET_WM_STATE_MAXIMIZED_VERT for vertical maximization), standardizing decoration states and button functionalities for consistent behavior in modern desktop environments. Session management ensures continuity by allowing window managers to save and restore window configurations. Through the X Session Management Library (SMlib), which implements the X Session Management Protocol (XSMP), window managers connect to a session manager using SmcOpenConnection and respond to save requests via callbacks like SmcSaveYourselfProc. During saving, properties such as SmRestartCommand are updated with window positions, sizes, and states (e.g., mapped or withdrawn) via SmcSetProperties, enabling full restoration—including reparenting to recreate decorations—upon session restart with SmcSaveYourselfDone confirming completion.

Operational Mechanics

Interaction with X Server

The X window manager operates as a specialized client within the X Window System's client-server architecture, communicating with the X server through protocol requests to manage window properties and behaviors. To resize, move, or restack windows, the window manager issues ConfigureWindow requests, which specify changes to attributes such as position (x, y coordinates), dimensions (width, height), border width, sibling window for stacking order, and stack mode (e.g., Above, Below, TopIf, or Opposite). Similarly, to control window visibility, it sends MapWindow requests to map unmapped windows, making them visible on the display and potentially triggering associated events for exposure or notification. These requests allow the window manager to enforce layout policies, such as positioning new windows according to stacking or tiling rules, while the X server processes them to update the window hierarchy. A key mechanism for the window manager's control is substructure redirection, achieved by selecting the SubstructureRedirect event mask on the root or relevant parent windows via the SelectInput request. This mask enables the window manager to intercept and mediate client-initiated requests on child windows, such as MapWindow or ConfigureWindow, preventing direct modifications by applications and allowing the manager to apply its policies instead—for instance, repositioning a window to fit a predefined grid or stack. Only one client can select this mask per window; attempts by others result in an Access error, ensuring exclusive management authority. The override-redirect window attribute can bypass this interception for certain transient windows, like menus or tooltips, permitting direct server handling without manager involvement. Window managers also interact with the X server through property management, reading and writing X properties—internally represented as atoms—to store and retrieve metadata about windows. For example, under the Extended Window Manager Hints (EWMH) specification, the window manager maintains the _NET_ACTIVE_WINDOW property on the root window, setting it to the ID of the currently focused window (or None if none) to inform other clients like pagers or taskbars of focus changes. Clients can request activation by sending a ClientMessage event with the _NET_ACTIVE_WINDOW atom to the root window, including details like the target window ID, source type (e.g., application or ), and , which the manager evaluates before potentially granting focus. These operations use ChangeProperty and GetProperty requests to manipulate atom-based properties, facilitating standardized inter-client communication. To maintain protocol integrity, window managers must handle errors arising from invalid requests, particularly BadWindow errors, which occur when a WINDOW parameter references an undefined or destroyed window ID. Such errors are reported asynchronously by the X server in a 32-byte format including the major and minor opcodes of the offending request, allowing the manager to detect issues like attempts to configure non-existent windows during dynamic rearrangements. Proper error handling involves installing custom error handlers via XSetErrorHandler to log or ignore non-fatal violations without crashing, ensuring robust operation amid concurrent client activities. This asynchronous error mechanism is crucial for window managers, as it prevents protocol mismatches from disrupting overall session stability.

Event Handling and Rendering

The X window manager operates within an , where it maintains an event queue to process incoming notifications from the X server. This queue handles various event types essential for user interaction and window management, including ButtonPress events, which signal activations on windows or decorations; KeyPress events, indicating keyboard inputs directed to focused windows; ConfigureRequest events, generated when clients request changes to window such as position or ; and PropertyNotify events, which alert the manager to modifications in window properties like hints or state information. According to the Inter-Client Communication Conventions Manual (ICCCM), the window manager must selectively process these events to enforce policies on window placement, focus, and decoration while adhering to client hints to avoid conflicts. Event updates in the X system are primarily asynchronous, with the server queuing events as they occur and delivering them to the appropriate client—the —in the order received, allowing for non-blocking responsiveness. However, synchronous behavior can be achieved through synthetic events generated via the XSendEvent function, which permits the to inject precise events like ConfigureNotify or synthetic UnmapNotify directly into the queue for immediate processing, ensuring coordinated state transitions such as window mapping or focus changes. This mechanism is crucial for the to simulate user actions or propagate decisions back to clients without relying solely on natural event flow. For basic rendering, the window manager employs low-level Xlib graphics primitives to draw essential elements like window borders and menus. Functions such as XDrawRectangle are used to outline frame borders and title bars, typically in response to Expose or ConfigureNotify events that require repainting exposed regions. More structured user interface components, such as popup menus, may leverage the X Toolkit Intrinsics (Xt) library for widget-based rendering, enabling efficient creation of hierarchical menus with callbacks for event dispatching, as seen in traditional managers like the . The core of event handling revolves around a main loop that monitors the X connection file descriptor for incoming events, often using system calls like select() or poll() to integrate with other input sources if needed. A typical structure in pseudocode illustrates this dispatch mechanism:

while (true) { fd_set read_fds; FD_ZERO(&read_fds); FD_SET(ConnectionNumber(display), &read_fds); int max_fd = ConnectionNumber(display) + 1; struct timeval timeout = {0, 0}; // Non-blocking poll if (select(max_fd, &read_fds, NULL, NULL, &timeout) > 0) { if (FD_ISSET(ConnectionNumber(display), &read_fds)) { XEvent event; XNextEvent(display, &event); switch (event.type) { case ButtonPress: handle_button_press(&event.xbutton); break; case KeyPress: handle_key_press(&event.xkey); break; case ConfigureRequest: handle_configure_request(&event.xconfigurerequest); break; case PropertyNotify: handle_property_notify(&event.xproperty); break; // Handle other events as needed default: break; } } } // Periodic tasks, e.g., window restacking }

while (true) { fd_set read_fds; FD_ZERO(&read_fds); FD_SET(ConnectionNumber(display), &read_fds); int max_fd = ConnectionNumber(display) + 1; struct timeval timeout = {0, 0}; // Non-blocking poll if (select(max_fd, &read_fds, NULL, NULL, &timeout) > 0) { if (FD_ISSET(ConnectionNumber(display), &read_fds)) { XEvent event; XNextEvent(display, &event); switch (event.type) { case ButtonPress: handle_button_press(&event.xbutton); break; case KeyPress: handle_key_press(&event.xkey); break; case ConfigureRequest: handle_configure_request(&event.xconfigurerequest); break; case PropertyNotify: handle_property_notify(&event.xproperty); break; // Handle other events as needed default: break; } } } // Periodic tasks, e.g., window restacking }

This loop ensures timely processing of the specified events while maintaining the manager's responsiveness, with handlers implementing ICCCM-compliant logic for each case.

Classification by Design

Stacking Window Managers

Stacking window managers in the utilize an overlapping paradigm, modeling the desktop as stacks of papers where windows can be arranged in a Z-order , permitting arbitrary overlaps among windows. This design allows subwindows to obscure others based on their depth, with operations like raising or lowering adjusting the stacking order without altering in-plane positions. The active window, typically the one receiving input focus, is raised to the top of the stack to ensure and , facilitating user interaction in a multitasking environment. Window managers control these restacking requests via mechanisms like ConfigureWindow, though they may override client suggestions to enforce user policies. Representative implementations of stacking window managers include the (mwm), developed as part of the OSF/Motif toolkit, which maintains a global stacking order for overlapping windows and supports raising focused windows automatically. Similarly, the OpenLook Window Manager (olwm), the default for ' OpenWindows environment, enables users to raise windows to the top via clicks on title bars or borders while allowing overlaps and multi-selection for batch operations. 's , the standard for the Plasma desktop since KDE 4.0, defaults to a stacking mode with floating windows that overlap freely, providing traditional desktop-like behavior. This overlapping approach offers advantages such as flexible resizing and positioning, which align with user expectations from conventional desktop metaphors, potentially improving task performance in scenarios involving visual scanning and manual arrangement. However, it can lead to disadvantages like screen waste, as obscured portions of underlying windows require additional to access. For interoperability, stacking window managers conform to the Inter-Client Communication Conventions Manual (ICCCM), which specifies protocols for handling (e.g., WM_HINTS, WM_STATE) and synthetic to ensure consistent client-window manager communication and resource mediation. Compliance with ICCCM or later allows clients to assume reliable stacking behaviors across implementations.

Tiling Window Managers

Tiling window managers for the arrange application windows in non-overlapping configurations to optimize available screen space, contrasting with stacking managers by automating layout decisions to prevent overlaps. These managers employ diverse tiling algorithms, categorized broadly as manual, dynamic, or static grid-based, each tailored to balance automation and user control in window placement. Manual tiling requires explicit user intervention to define window arrangements, as seen in i3, where keyboard shortcuts such as Mod+h for horizontal splits or Mod+v for vertical splits create a hierarchical tree of containers, allowing precise control over splits, tabs, or stacks. In contrast, dynamic tiling algorithms automatically adjust layouts based on window count and focus, exemplified by xmonad's default tiled layout, which partitions the screen into a master pane for the primary window and a stack for others, using the (approximately 0.618) to proportion the master area for balanced visibility. similarly applies dynamic tiling by dividing the screen into a master area and stacking region, with layouts like tiled or adapting in real-time to the number of open windows. Static grid approaches, such as in herbstluftwm, impose fixed divisions resembling a grid, though less common, to enforce uniform partitioning without user-specified splits. Workspace management in these systems typically supports multiple virtual desktops, enabling users to segregate tasks across independent screens, often with tagging mechanisms for enhanced organization. Tagging, prominent in and Awesome, assigns labels to windows rather than rigid workspaces, allowing a single window to appear across multiple tags or views, facilitating fluid grouping without duplicating instances. Awesome, for instance, leverages tags as dynamic equivalents to workspaces, configurable via scripts to display overlapping sets on setups. bspwm extends this through , modeling the screen as a where each node represents a split (horizontal or vertical) with adjustable ratios, supporting manual insertion for user-directed placements or automatic modes like longest-side for even distribution. Navigation and interaction emphasize keyboard-centric controls, with customizable bindings in tools like i3 for focus shifting (e.g., Mod+j/k/l/;), window movement, and layout toggles, minimizing reliance on the for power users. Examples such as , Awesome, and bspwm pair these with external handlers like sxhkd for key mappings, promoting seamless transitions between windows and workspaces. The primary benefits of tiling window managers include maximal utilization of screen real estate through borderless or minimal framing, ensuring no wasted space from overlaps, which suits multi-window workflows on limited displays. This efficiency boosts productivity for advanced users by streamlining keyboard-driven multitasking and reducing visual clutter, though the emphasis on configuration files and bindings introduces a for initial setup and customization.

Compositing Window Managers

Compositing window managers in the extend traditional window management by incorporating off-screen rendering and visual effects, rendering each window's content to an off-screen pixmap before combining these pixmaps into the final screen image. This process enables advanced features such as drop shadows, transparency, and animations, which are achieved by applying blending operations during the stage. The core of this functionality relies on X11 extensions, particularly the XComposite extension, which allows windows to be redirected to off-screen storage, preventing direct rendering to the screen and facilitating per-window hierarchy management. Complementing this, the XRender extension provides mechanisms for alpha blending, , and image composition primitives, enabling smooth transitions and visual overlays without altering the underlying window stacking order. Notable implementations include Compiz, a compositing window manager that leverages for hardware-accelerated effects, such as the "wobbly windows" plugin, which simulates jelly-like deformation during window movement. Another example is Xfwm4, the default window manager for the , which integrates a built-in compositor supporting transparency and shadows while maintaining synchronization with window events for consistent visual feedback. Performance in compositing window managers is enhanced through GPU acceleration via the extension, which binds off-screen pixmaps to textures for efficient rendering on supported hardware, as seen in Compiz's 3D effects . In environments lacking suitable GPU support, fallback to software rendering occurs, relying on CPU-based operations through XRender, which can increase latency but ensures basic availability.

Dynamic and Hybrid Types

Dynamic and hybrid types of X s extend traditional classifications by incorporating adaptable layouts, virtual workspaces, and modular architectures that blend elements such as stacking, tiling, and extensibility. These managers often support s, where the effective workspace exceeds the physical display, enabling users to navigate larger areas through paging or mechanisms. For example, tvtwm, a variant of the , adds functionality by allowing specification of a desktop size larger than the screen, with navigation via mouse panning or keyboard commands. Similarly, vtwm, derived from , implements a as an extended area beyond the screen boundaries, supporting smooth and icon placement across the virtual space. Early implementations of virtual support include olvwm, the OPEN LOOK virtual window manager, which builds on olwm by introducing virtual screen extensions for managing windows in a paged environment compliant with ICCCM standards. Extensible designs further enhance flexibility through scripting interfaces or plugin systems. Ion3, a tiling and tabbed window manager, employs scripting for runtime configuration, permitting dynamic adjustment of layouts and inclusion of a basic floating window mode that hybrids tiling with stacking behaviors. Herbstluftwm exemplifies hybrid approaches by combining manual tiling—via binary tree-based frame splitting—with a dedicated floating layer for overlapping windows, allowing seamless mode switching between tiled and stacked arrangements. The EWMH (Extended Window Manager Hints) and NetWM standards promote interoperability in dynamic and hybrid setups, particularly for management. These specifications define root window properties such as _NET_NUMBER_OF_DESKTOPS for dynamically setting the count of desktops and _NET_CURRENT_DESKTOP for switching via client messages, while _NET_DESKTOP_VIEWPORT enables scrolling in larger-than-screen desktops. Support for virtual roots through _NET_VIRTUAL_ROOTS allows to subwindows, facilitating paged desktops where the advances in fixed screen-sized increments. This evolution from early virtual extensions in managers like olvwm to scripting-enabled modularity in tools like Ion3 has enabled more adaptable X11 environments.

Historical Development

Origins in X11

The , which laid the foundation for independent window managers, originated within at the (MIT) in 1984 as a collaborative effort to develop networked graphical interfaces for Unix workstations. Led by Robert W. Scheifler, the project began on June 19, 1984, building on the earlier by introducing an asynchronous bitmap protocol to support environments. This initiative addressed the need for a flexible, hardware-agnostic display server that could handle multiple clients over networks, enabling pluggable user interfaces without tying them to specific hardware or proprietary toolkits. The inaugural release, X10, arrived in late 1985 and featured the Ultrix Window Manager (uwm) as its basic window management component, providing core functionalities such as window creation, resizing, and movement. Developed initially for DEC's operating system, uwm represented an early attempt to separate window decoration and management from the core X server, allowing applications to focus on content rendering while the manager handled user interactions. This separation was crucial for the system's modularity, though uwm was rudimentary and tied to specific hardware quirks, like DEC keyboards, during initial ports to platforms such as Sun workstations. X11, released on September 15, 1987, marked a pivotal advancement with enhanced portability and the introduction of the Inter-Client Communication Conventions Manual (ICCCM), which standardized interactions between clients and s. Authored by David S. H. Rosenthal, the ICCCM specified protocols for essential features like selections, cut buffers, and window manager hints, ensuring interoperability and reducing chaos in multi-application environments. In X11's initial releases (R1 through R3), uwm continued as the default manager, but it was supplanted in X11R4 (1989) by (Tab Window Manager), created by Tom LaStrange, which added configurable title bars, shaped windows, and icon management for improved usability. A key motivation behind X's architecture was to foster pluggable, interchangeable user interfaces in Unix systems, avoiding the monolithic integration seen in competitors like ' , which embedded rendering directly into the server for richer graphics but at the cost of portability and vendor neutrality. By licensing X under the open and emphasizing a lightweight core protocol, the design encouraged community-driven development, promoting widespread adoption across diverse Unix vendors and preventing lock-in to closed ecosystems. This approach proved instrumental in establishing X as the for graphical computing in academic and enterprise Unix settings during the late .

Evolution and Key Milestones

In the late 1990s and early 2000s, the Extended Window Manager Hints (EWMH) emerged as a key standard to enhance interoperability between window managers and desktop environments like and , building on the earlier Inter-Client Communication Conventions Manual (ICCCM) by providing hints for window states, placements, and decorations. The specification's initial versions, such as 1.1 released in March 2001, formalized these interactions, enabling more consistent behavior across stacking window managers in multi-desktop environments. Concurrently, the rise of capabilities marked a significant shift, with the X Rendering Extension (XRender) introduced in 2000 as part of 4.0, allowing for alpha blending, , and image composition directly in the X server to support smoother without relying on external software. This extension laid the groundwork for window managers, improving rendering efficiency and enabling features like transparency and shadows. The 2000s saw the growing popularity of tiling window managers, starting with early implementations like Larswm and in 2000, which automated window arrangement to maximize screen space and appealed to users seeking efficient workflows on limited hardware. This trend accelerated post-2002 with minimalist designs emphasizing keyboard-driven automation, culminating in projects like released in 2007, which popularized dynamic tiling through declarative configuration in . By the early 2010s, alternatives to the X protocol began to emerge, with Wayland announced in 2012 as a modern display server protocol aimed at addressing X11's limitations in security, performance, and multi-monitor support, initially developed by . Security enhancements also evolved, with the XSecurity extension, introduced in 1996, providing a trusted/untrusted client model to mitigate risks like unauthorized access in networked environments, though it remained limited in scope. In the and , X window managers deepened integration with desktop environments, exemplified by Mutter becoming GNOME's default compositor in 2011 with , combining window management and compositing using Clutter for hardware-accelerated effects. This period also highlighted a gradual decline in pure X11 usage, as distributions increasingly favored Wayland for its improved isolation and efficiency, with hybrid approaches bridging the transition. Recent developments include dynamic tiling compositors like Hyprland, released in 2022, which operate on Wayland but reflect ongoing innovations in window management paradigms originally rooted in X traditions.

Configuration and Customization

Basic Setup Methods

The basic setup of an X window manager involves installing the software, configuring initial files, and launching it either manually or through a display manager. Installation is typically handled via distribution package managers. On Debian and Ubuntu systems, the i3 tiling window manager can be installed with sudo apt install i3, which pulls in necessary dependencies like xorg and related libraries. Similarly, the traditional twm stacking window manager is available via sudo apt install twm. On Fedora, use sudo dnf install i3 to install i3, or sudo dnf install twm for twm, ensuring the X.Org server packages are present. These commands provide pre-compiled binaries, avoiding the need for manual compilation in most cases. For users preferring to build from source, modern window managers like i3 use the build system. Clone the repository with git clone https://github.com/i3/i3.git, create a build directory with mkdir build, configure with meson setup build, compile with meson compile -C build, and install with sudo meson install -C build, after installing dependencies such as libxcb1-dev, libyajl-dev, libev-dev, libpcre2-dev, and others on Debian-based systems. Older window managers like , part of the X.Org distribution, historically relied on imake for builds but transitioned to autotools in releases like twm 1.0.5 for improved . The X.Org build process downloads sources via a script that handles dependencies in order. Default configurations are provided to enable immediate usability without extensive editing. For twm, the system-wide default is in /usr/share/X11/twm/system.twmrc, which can be copied to ~/.twmrc for user-specific tweaks; it defines basic variables like fonts, colors, and menus, with built-in fallbacks for titlebars and icon management if no file is present. For i3, the initial config is generated on first launch via the i3-config-wizard, saved to ~/.config/i3/config (or /etc/i3/config system-wide), setting defaults like Alt as the , terminal launch on $mod+Enter, and workspace switching on $mod+1 through $mod+0. Environment variables like WINDOW_MANAGER can specify the preferred manager (e.g., export WINDOW_MANAGER=i3) for session selection in some setups. Launching occurs through integration with X startup mechanisms. Without a display manager, edit ~/.xinitrc to include exec <window-manager>, such as exec i3 for i3 or exec [twm](/page/Twm) for twm, then start the session with startx. With a display manager like GDM or , create or edit ~/.xsession with the same exec line, or select the manager from the login menu if a .desktop file is installed (e.g., /usr/share/xsessions/i3.desktop). twm served as a historical default in early X11 distributions, providing a minimal stacking interface out of the box. To test a window manager standalone without affecting the primary session, use xinit -- :1 from a console (e.g., Ctrl+Alt+F2), which starts an X server on display :1 and loads the manager via .xinitrc; switch back with Ctrl+Alt+F7 and terminate with Ctrl+C on the test console. This isolates the session for verification before full integration.

Advanced Features and Extensions

Advanced configuration of X window managers frequently utilizes the ~/.Xresources file to define that control client appearance and behavior, such as colors, fonts, and geometry for decorations. This mechanism, part of the core X11 resource database, allows fine-grained customization without recompiling the software, and changes are typically applied by merging the file with xrdb -merge ~/.Xresources. Certain tiling window managers, for instance, rely on executable key files like bspwmrc, a that invokes the bspc utility to establish rules, keybindings, and monitor layouts at startup. Similarly, the wmii window manager employs scripts for configuration, supporting languages such as or Python to interact with its 9P filesystem interface for dynamic control over management events and actions. X11 extensions significantly expand window manager capabilities beyond basic functionality. , an X server extension, facilitates multi-monitor setups by unifying multiple physical displays into a single logical screen, enabling windows to span across monitors seamlessly, though it has been largely superseded by RandR in modern implementations. The Xft library, leveraging the Render extension, delivers anti-aliased font rendering, which enhances the visual quality of text in titles, menus, and status bars by supporting and scalable fonts from . For further enhancements, users often patch the source code of window managers to incorporate custom features, such as novel layout algorithms or input handling, following standard open-source development practices exemplified in tutorial implementations. Theming in X window managers involves setting color schemes through properties defined in the Extended Window Manager Hints (EWMH) specification, which standardizes interactions for desktop environments and allows consistent application of visual styles across windows. These properties, such as _NET_WM_STATE and _NET_WM_WINDOW_TYPE, enable window managers to apply theme-specific colors to decorations while ensuring compatibility with pagers and taskbars. Integration with external panels, like tint2, further supports theming by reserving screen space via EWMH struts and syncing window states for accurate task switching and system tray icons. Troubleshooting advanced setups commonly addresses issues like focus stealing, where new windows unexpectedly capture input; prevention relies on the Inter-Client Communication Conventions Manual (ICCCM) focus model, supplemented by the XFixes extension for precise event handling and cursor synchronization. The XFixes extension provides mechanisms such as selection notifications and pointer barriers, aiding window managers in maintaining stable focus policies without intrusive interventions.

Notable Implementations

Traditional Examples

, originally released in 1988 as Tom's Window Manager, serves as a foundational for the , providing essential features like titlebars, icon management, and configurable key bindings through its .twmrc file. It became the default with X11R4 and emphasizes simplicity, with no built-in support in its core, though extensions and forks later addressed this. Due to its minimal memory and CPU requirements, persists in legacy and minimal X installations, such as those in or base systems, where resource efficiency is paramount for older hardware or embedded use. Fvwm, a 1993 fork of twm developed by Robert Nation, expanded on its predecessor by introducing themeable decorations, modular extensions for features like pagers and icon boxes, and support for virtual desktops across multiple workspaces. Successive variants, including Fvwm2 (mid-1990s) and Fvwm3 (2000s onward), refined these elements with improved FML configuration syntax and dynamic module loading, enabling users to build complex setups without bloating the core binary. This architecture keeps Fvwm highly customizable yet resource-efficient, making it a staple in legacy systems and lightweight distributions where performance on constrained hardware remains critical. Metacity, introduced in 2001 and established as the default window manager for 2 starting in 2002, offers a straightforward stacking model designed for seamless integration with applications via GTK+. It fully implements the Extended Window Manager Hints (EWMH) and ICCCM standards, supporting workspace switching, window focus policies, and desktop notifications, with basic compositing support. With a focus on reliability over flashiness, Metacity's relatively low overhead ensures its ongoing role in legacy environments, such as MATE or Flashback on older systems. These traditional window managers exemplify early X innovations, with , , and collectively powering countless legacy installations due to their proven stability and resource efficiency, historically outperforming alternatives on hardware from the and .

Modern and Specialized Variants

One prominent modern for X11 is i3, first released in 2010 and designed for keyboard-driven operation to enhance productivity among developers and advanced users. i3 automatically arranges windows in a non-overlapping grid layout, supporting features like gapless tiling to eliminate spacing between windows and an (IPC) interface that enables scripting and external control for custom behaviors. Its configuration relies on a plain-text file, promoting simplicity and extensibility without requiring graphical tools. Among specialized variants, stands out as an Emacs-inspired for X11, initially released in 2000 but maintaining relevance in minimalist environments due to its screen-filling, mouse-avoidant philosophy. It emulates the terminal multiplexer, using keyboard commands to switch and resize windows without decorations or spatial dragging, enforcing a full-screen for focused workflows. This design minimizes distractions and dependencies, aligning with ratpoison's core tenet of rodent-free operation. Another notable tiling window manager is Awesome, first released in 2007, which combines the flexibility of a dynamic tiling system with extensive theming and Lua-based scripting for advanced customization. It supports multiple layouts, including tiling, floating, and maximized modes, and integrates well with EWMH-compliant applications, making it popular for users seeking a balance between automation and manual control in X11 environments. , originating as a of in 2002 and actively maintained through 2025, is a lightweight emphasizing minimalism and standards compliance. It provides right-click menus for window operations, supports per-application rules, and serves as the default in lightweight desktops like and , offering efficient management without unnecessary features. These modern and specialized window managers, including i3, , Awesome, and , have seen rising adoption in minimalistic distributions like , where users prioritize efficiency and customization over full desktop environments, often installing them via package managers for lightweight setups. Their integration into Arch's ecosystem, supported by detailed community documentation, facilitates rapid deployment in resource-constrained or performance-oriented systems.

References

  1. https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
  2. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/reference_guide/s2-x-clients-winmanagers
  3. https://arstechnica.com/gadgets/2024/06/the-x-window-system-is-40-archaic-as-heck-and-still-relevant/
  4. https://apps.hci.rwth-aachen.de/borchers-old/cs377a/materials/p79-scheifler.pdf
  5. https://docs.oracle.com/cd/E26502_01/html/E28056/gmdam.html
  6. https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
  7. https://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html
  8. https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
  9. https://www.x.org/docs/ICCCM/icccm.pdf
  10. https://man.archlinux.org/man/X11::Protocol::WM.3pm.en
  11. https://tronche.com/gui/x/xlib/window/attributes/gravity.html
  12. https://www.ist.co.uk/motif/books/vol6A/ch-20.fm.html
  13. https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#input_focus
  14. https://www.x.org/archive/X11R6.8.1/doc/twm.1.html
  15. https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_name_property
  16. https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_protocols_property
  17. https://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html#SmcOpenConnection
  18. https://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html#SmcSetProperties
  19. https://www.x.org/releases/X11R7.7/doc/libSM/SMlib.html#SmcSaveYourselfDone
  20. https://www.rfc-editor.org/rfc/rfc1013.html
  21. https://specifications.freedesktop.org/wm-spec/latest-single
  22. https://tronche.com/gui/x/xlib/graphics/drawing/XDrawRectangle.html
  23. https://linux.die.net/man/1/mwm
  24. https://manpages.debian.org/jessie/olvwm/olwm.1olvwm
  25. https://userbase.kde.org/Tutorials/Using_Other_Window_Managers_with_Plasma
  26. https://dl.acm.org/doi/10.1145/22339.22356
  27. https://wiki.archlinux.org/title/Comparison_of_tiling_window_managers
  28. https://i3wm.org/docs/userguide.html
  29. https://dwm.suckless.org/
  30. https://awesomewm.org/
  31. https://github.com/baskerville/bspwm
  32. https://www.howtogeek.com/what-is-a-tiling-window-manager/
  33. https://www.x.org/releases/X11R7.6/doc/renderproto/renderproto.txt
  34. https://www.x.org/releases/current/doc/man/man3/Xcomposite.3.xhtml
  35. https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt
  36. https://wiki.archlinux.org/title/Compiz
  37. https://docs.xfce.org/xfce/xfwm4/introduction
  38. https://download.nvidia.com/XFree86/Linux-x86_64/396.51/README/xcompositeextension.html
  39. https://www.freshports.org/x11-wm/tvtwm
  40. http://www.vtwm.org/
  41. https://www.freshports.org/x11-wm/olvwm
  42. https://github.com/jan0sch/Ion3
  43. https://herbstluftwm.org/
  44. https://blog.dshr.org/2024/07/x-window-system-at-40.html
  45. https://www.x.org/wiki/X11R1/
  46. https://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html
  47. https://wiki.archlinux.org/title/Twm
  48. https://www.theregister.com/2024/07/10/dshr_on_news_vs_x/
  49. https://specifications.freedesktop.org/wm-spec/1.4/
  50. https://www.linux.co.cr/desktops/review/acrobat/010310.pdf
  51. https://wayland.freedesktop.org/releases.html
  52. https://www.x.org/releases/X11R7.6/doc/xextproto/security.html
  53. http://www.linux-magazine.com/Online/News/Mutter-Window-Manager-in-GNOME-s-Future
  54. https://github.com/hyprwm/Hyprland/releases
  55. https://i3wm.org/docs/repositories.html
  56. https://i3wm.org/docs/hacking-howto.html
  57. https://lists.x.org/archives/xorg/2010-October/051459.html
  58. https://www.x.org/wiki/Building_the_X_Window_System/
  59. https://manpages.debian.org/bullseye/twm/twm.1.en.html
  60. https://wiki.archlinux.org/title/Environment_variables
  61. https://faq.i3wm.org/question/6126/how-do-i-start-i3/index.html
  62. https://www.x.org/archive/X11R7.5/doc/man/man1/xinit.1.html
  63. https://www.oreilly.com/library/view/x-window-system/9780937175149/Chapter09.html
  64. https://github.com/sunaku/wmii
  65. https://www.x.org/archive/X11R7.0/doc/html/RELNOTES4.html
  66. https://www.oreilly.com/library/view/x-power-tools/9780596101954/ch11.html
  67. https://github.com/jichu4n/basic_wm
  68. https://github.com/semplice/tint2
  69. https://github.com/Airblader/unclutter-xfixes
  70. https://wiki.alpinelinux.org/wiki/Twm
  71. https://opensource.com/article/19/12/twm-linux-desktop
  72. https://www.fvwm.org/
  73. https://opensource.com/article/19/12/fvwm-linux-desktop
  74. https://gitlab.gnome.org/GNOME/metacity
  75. https://www.freshports.org/x11-wm/metacity
  76. http://www.informit.com/content/images/9780672329425/samplechapter/0672329425_CH03.pdf
  77. https://i3wm.org/
  78. https://wiki.archlinux.org/title/i3
  79. https://www.nongnu.org/ratpoison/
  80. https://wiki.archlinux.org/title/Ratpoison
  81. https://wiki.gentoo.org/wiki/Ratpoison
  82. https://openbox.org/
  83. https://wiki.archlinux.org/title/Window_manager
Add your contribution
Related Hubs
User Avatar
No comments yet.