Window manager
A window manager is system software that controls the placement, appearance, and behavior of windows within a windowing system of a graphical user interface (GUI).[1] It manages tasks such as drawing window frames, handling resizing and movement, directing user input focus, and adding decorative elements like title bars, borders, and icons.[2] In systems like Unix-like operating environments, window managers function as clients of the underlying windowing system, such as the X Window System, which provides basic graphics and input handling but delegates layout control to the manager.[1] Similarly, in Microsoft Windows, the Desktop Window Manager (DWM) serves as a compositing manager, enabling visual effects like transparency and animations while overseeing window rendering.[3] In Apple's macOS, the Aqua interface uses an integrated window manager for window compositing and effects.[4] The origins of window managers trace back to early human-computer interaction research in the late 1960s, with Doug Engelbart's NLS system (1968) introducing tiled windows and mouse-driven manipulation on a display.[5] Alan Kay's 1969 doctoral thesis proposed overlapping windows, which were realized in 1974 by Xerox PARC's Smalltalk and InterLisp systems, featuring basic management for multitasking on shared screens.[5] The Xerox Star (1981) commercialized these ideas with a full widget set, including scrollbars and menus, influencing subsequent GUIs.[5] By the mid-1980s, the X Window System—initially developed at MIT in 1984 and standardized as X11 in 1987—formalized window managers as independent programs, allowing customizable layouts like overlapping or tiled arrangements.[6] Contemporary window managers are categorized by their layout philosophies: stacking managers permit overlapping windows with manual positioning (e.g., twm or Metacity), tiling managers automatically arrange non-overlapping windows to maximize screen use (e.g., i3 or Awesome),[7][8] and dynamic or compositing variants blend these with effects like blurring.[9] They often integrate into desktop environments, such as GNOME's Mutter or KDE's KWin, which extend management with workspaces, theming, and accessibility features.[10][11] Proposed innovations as of 2023, including adaptive "mosaic" modes and app-specific sizing metadata in GNOME, aim to address longstanding challenges like visual clutter and hidden windows in multi-tasking scenarios, though core implementation remains ongoing as of 2025.[12][13]Fundamentals
Definition and Purpose
A window manager (WM) is system software that controls the placement, appearance, size, and movement of windows within a graphical user interface (GUI), acting as an intermediary between applications and the display server.[14][15] In this role, it operates as a client program in systems like the X Window System, managing top-level windows without direct hardware access.[15] The primary purposes of a window manager include managing input focus to determine which window receives user events, drawing window decorations such as title bars, borders, and control buttons, and handling operations like resizing, minimizing, maximizing, and closing windows.[2][15] It mediates competition for screen space among applications by interpreting client hints on preferred sizes and positions, ensuring efficient resource allocation without applications needing to manage overlaps or input routing directly.[14] Unlike full desktop environments, which incorporate additional elements like panels, file managers, and theming systems, a window manager focuses solely on window lifecycle and presentation, allowing modular integration into broader GUI ecosystems.[14] In terms of basic architecture, window managers interact with underlying display protocols such as X11 or Wayland to render and update windows; for instance, in X11, they use substructure redirection to intercept window requests and communicate via properties and messages through the X server.[15][14] In Wayland, the window manager functionality is often integrated into the compositor process, which handles both rendering and input directly with clients using shared buffers.[16] This design emerged in the 1980s as graphical user interfaces proliferated on bitmap displays, addressing the chaos of unmanaged overlapping windows in early systems like the X Window System developed at MIT.[14] Variations such as stacking and tiling window managers represent different approaches to fulfilling these core purposes, with stacking allowing overlaps and tiling enforcing non-overlapping layouts.[14]Relationship to GUI Components
Window managers operate as a distinct layer within graphical user interfaces (GUIs), relying on underlying display servers for low-level rendering and hardware interaction while managing higher-level window orchestration. In systems like X11, the display server (e.g., X.org) handles primitive drawing operations, input event routing, and resource allocation, whereas the window manager acts as an intermediary client that intercepts and decorates windows without direct access to the graphics hardware.[17] This separation ensures modularity, with the window manager communicating via standardized protocols such as the Inter-Client Communication Conventions Manual (ICCCM), which defines conventions for client-to-window-manager interactions, including window state changes and property management.[18] In contrast, Wayland integrates display server functionalities into compositors, which often encompass window management roles, blurring the lines but preserving the window manager's focus on layout and behavior over raw rendering.[19] Within desktop environments (DEs), window managers serve as the foundational component for window handling, integrated atop which higher-level elements like panels, file managers, and application launchers function. For instance, GNOME employs Mutter as its window manager, which provides the core logic for window placement and manipulation while supporting the GNOME Shell's user interface extensions.[10] Similarly, KDE Plasma uses KWin to manage windows, enabling seamless integration with the DE's theming and widget systems.[20] This bundling allows DEs to leverage the window manager's capabilities for consistent user experiences, but the window manager itself remains agnostic to DE-specific features, focusing solely on generic window lifecycle and positioning. Window managers differ from compositors, though overlap exists in modern implementations; compositors manage off-screen buffering for visual effects like transparency and animations, a capability not inherent to pure window managers. Some window managers incorporate compositing (e.g., via extensions in X11), but in Wayland, standalone compositors fulfill both roles, handling direct rendering and window stacking without a separate non-compositing manager.[17] The key distinction lies in scope: compositors prioritize graphical synthesis across surfaces, while window managers enforce policies on window visibility, focus, and geometry. To ensure interoperability, window managers interact with applications through standards like the Extended Window Manager Hints (EWMH), which extend ICCCM to specify properties for window states, types, and actions, promoting uniform behavior across diverse programs.[21] EWMH enables applications to request specific placements or roles (e.g., via _NET_WM_STATE for maximization) and allows window managers to broadcast supported features through root window properties, facilitating tools like taskbars in querying window lists.[21] Despite their central role, window managers have defined limitations, eschewing direct control over input devices—which is managed by the kernel and display server—and system-wide theming, which DEs typically oversee through configuration layers like GTK or Qt themes. Input events, such as keyboard or mouse actions, are routed by the display server to appropriate clients, bypassing the window manager except for focus mediation.[22] Theming, involving icon sets and color schemes, resides in the DE's domain to maintain coherence across applications, leaving window managers to apply only frame-specific decorations.[23]Historical Development
Origins in Early Computing
The origins of window managers trace back to pioneering research in interactive computing during the 1960s, where early systems introduced concepts of multiple display regions to enhance user interaction on limited screens. Ivan Sutherland's Sketchpad, developed in 1963 at MIT's Lincoln Laboratory on the TX-2 computer, represented a foundational precursor by introducing the first interactive graphical interface with light pen manipulation and clipping within defined display areas. This allowed users to work with graphical elements directly, pioneering algorithms to manage content within boundaries. Similarly, Douglas Engelbart's oN-Line System (NLS), demonstrated in 1968 at SRI International, advanced these ideas with tiled windows that could split screens horizontally or vertically, supporting cross-window editing and navigation via the newly invented mouse. These vector-display-based systems laid the groundwork for overlapping and dynamic window concepts, though they operated without bitmap graphics, focusing instead on line drawings and text augmentation. The transition to bitmap displays in the 1970s marked a significant evolution, with the Xerox Alto computer, introduced in 1973 at Xerox PARC, featuring the first primitive windowing system with overlapping frames managed entirely by software. The Alto's bit-mapped screen enabled mouse-driven selection, resizing, and dragging of windows, allowing users to overlap multiple frames for multitasking on a single display. Over 1,200 Alto units were built and tested, demonstrating practical window manipulation in a research environment. Building on this, Xerox PARC's Smalltalk environment, led by Alan Kay starting in 1972, introduced dynamic window handling primitives including tiling and stacking, leveraging bit-mapped displays and the BitBlt operation for efficient scrolling, resizing, and dragging of overlapping windows. These innovations emphasized object-oriented principles, where windows acted as interactive objects, influencing subsequent GUI designs. The move to commercial products in the early 1980s brought window management to broader audiences, as seen in Apple's Lisa system released in 1983, which implemented an early window manager for icon-based desktops supporting up to 20 overlapping windows with user control over size, position, and focus. The follow-up Apple Macintosh in 1984 popularized these features on affordable hardware, handling basic overlap and focus management without advanced reparenting, and achieving over 2 million units sold. Early window managers like those in the Lisa and Macintosh addressed key challenges in hardware-limited environments, lacking acceleration, by prioritizing efficient repainting of exposed regions through damage control mechanisms that updated only altered screen areas to minimize computational overhead. This focus on selective redrawing ensured responsive interactions despite the constraints of contemporary processors and displays.Evolution in Modern Operating Systems
The X Window System, introduced in 1984 at MIT as a client-server architecture, fundamentally separated the display server from window management responsibilities, enabling flexible window managers to run as clients atop the server.[24] This design facilitated the development of early window managers like the Simple Window Manager (swm) in the mid-1980s, which provided basic stacking functionality without advanced configuration. By 1989, the Tab Window Manager (twm), developed by Tom LaStrange, emerged as one of the first configurable stacking window managers, serving as the default for many X11 installations and introducing features like virtual desktops and icon management.[25] The 1990s saw proliferation of alternatives, including the Motif Window Manager (mwm), released in 1991 as part of the OSF Motif toolkit, which standardized appearance and behavior for Unix workstations through its reparenting model and decorum support.[26] In the 1990s, window manager diversification accelerated with the rise of desktop environments and alternative paradigms. Early experiments in tiling window management appeared in systems like Plan 9, where the rio window manager (introduced around 1992) used a tiled layout to optimize screen space without overlapping windows, influencing later Unix-like implementations.[25] The launch of KDE in 1998 integrated the KDE Window Manager (kwm), a stacking manager with customizable decorations and effects, while GNOME, released in 1999, initially paired with Sawfish—a Lisp-configurable stacking manager emphasizing extensibility and smooth animations—to provide a cohesive user experience.[27] These integrations marked a shift toward user-friendly, themeable environments amid growing Unix desktop adoption. The 2000s brought a compositing boom, driven by hardware advancements and the demand for visual effects. Metacity, introduced in 2002 as GNOME's default window manager, laid groundwork for compositing by supporting basic window grouping and focus stealing prevention, evolving to include offscreen rendering by GNOME 2.24 in 2008.[28] Compiz, released in early 2006, pioneered open-source 3D compositing on X11 using OpenGL for hardware-accelerated effects like window wobbling and cube desktops, significantly influencing desktop aesthetics and performance. This era emphasized leveraging graphics hardware for smoother interactions, transitioning from software rendering to GPU-accelerated pipelines. From the 2010s onward, the Wayland protocol addressed X11's limitations in security and efficiency, with initial development starting in 2008 by Kristian Høgsberg and its 1.0 release in October 2012; Weston, the reference compositor, debuted the same year as a minimal Wayland-based window manager.[29] Adoption gained momentum when Fedora 25 made Wayland the default for GNOME sessions in November 2016, followed by Ubuntu enabling it as default in version 21.04 (April 2021) and fully committing by 24.04 LTS in 2024.[30] The XWayland compatibility layer, introduced around 2016, ensures seamless support for legacy X11 applications during this transition.[31] In proprietary systems, parallel evolutions occurred. Microsoft Windows 1.0, released on November 20, 1985, featured a rudimentary window manager supporting tiled and cascaded arrangements along with iconic modes, without overlapping windows. This evolved to the Aero interface in Windows Vista (January 30, 2007), introducing compositing with transparency, live thumbnails, and Flip 3D navigation via the Desktop Window Manager (DWM) and DirectX.[32] On macOS, the Aqua interface debuted with Mac OS X 10.0 in March 2001, powered by the Quartz Compositor for PDF-based rendering and smooth animations, replacing the classic Mac OS's non-composited approach.[33] By the 2020s, trends emphasize security, input modernity, and portability. Wayland's architecture enhances security through per-client sandboxing and elimination of X11's global access vulnerabilities, as seen in GNOME 50's Wayland-only mandate in 2025, which isolates applications to prevent screen scraping and unauthorized input injection.[34] Compositors increasingly support touch and gesture interactions, with GNOME and KDE on Wayland enabling multi-touch window manipulation and swipe gestures since the mid-2010s. Cross-platform frameworks like Electron, which powers applications such as Visual Studio Code, leverage native window managers (e.g., via Chromium's Wayland backend) for consistent behavior across Linux, Windows, and macOS, though challenges like resizing persist without explicit configuration.[35]Types
Stacking Window Managers
Stacking window managers operate by layering windows in a Z-order stack, where each window is positioned relative to its siblings, allowing them to overlap freely while the server handles clipping to display only visible portions.[36] The active window is typically raised to the top of the stack upon receiving input focus, which can be managed through models such as click-to-focus, where focus shifts only on explicit user clicks, or focus-follows-mouse (also known as sloppy focus), where the pointer's position determines the focused window.[37] These mechanisms ensure that input events are directed to the appropriate window based on its stacking position and focus state, with the X server generating events like FocusIn and FocusOut to notify clients of changes.[36] A key aspect of stacking window managers is the reparenting model, in which the manager creates a decorative frame window around each client application window, reparenting the client as its child to intercept input and expose events for handling borders, titlebars, and controls.[37] This is achieved via the ReparentWindow request, which unmaps the client if necessary, changes its parent to the frame, and remaps it, generating a ReparentNotify event while preserving the client's coordinates relative to the new parent.[36] By managing this hierarchy, the window manager can enforce consistent decorations and behaviors without altering the client's core rendering, though clients must handle potential unmapping during state transitions like iconification.[37] This approach offers advantages in intuitiveness for traditional desktop metaphors, enabling users to arrange windows arbitrarily to mimic physical overlap and prioritize visible content, which supports flexible workflows in multi-tasking environments.[38] However, it requires manual user intervention for placement and resizing, often leading to screen clutter and occlusion as windows pile up without automatic organization.[39] Configuration is generally scriptable, as in X11 environments where the ~/.xinitrc file specifies the window manager launch and initial setup, allowing policies for initial window placement that range from algorithmic heuristics (e.g., avoiding overlaps with existing windows) to user-defined rules via hints like WM_NORMAL_HINTS.[37] Historically, stacking window managers dominated early graphical interfaces, serving as the foundation for implementations like twm, developed in 1987 by Tom LaStrange and adopted as the standard for X11R4 in 1989, which introduced features such as titlebars and icon management while relying on the reparenting model for decoration.[40] This paradigm influenced subsequent systems, providing the overlapping model that remains central to conventional desktop use, in contrast to non-overlapping alternatives like tiling managers.[37]Tiling Window Managers
Tiling window managers automatically arrange windows in non-overlapping layouts to maximize the use of available screen space, ensuring that each window occupies a dedicated region without overlap. This approach contrasts with traditional stacking methods by enforcing a structured division of the desktop, often resulting in tree-like hierarchies that adapt to the number and type of open applications. By prioritizing automation over manual placement, these managers aim to streamline workflows, particularly for users focused on keyboard navigation and multi-tasking. The core layout principles revolve around dividing the screen into geometric regions using techniques like binary space partitioning (BSP), where windows serve as leaves in a full binary tree structure, and the desktop is recursively partitioned into subspaces.[41] Common configurations include master-slave tilings, in which a primary master window claims a larger area (often on one side) while slave windows share the remainder in a stacked or equal division, or equal-area tilings that allocate space uniformly across all windows to promote balanced visibility.[42] Automation governs much of the arrangement process, with predefined rules for splitting screen regions—typically alternating between horizontal and vertical orientations when new windows open—to maintain efficient use of space. Windows can be swapped between regions dynamically, and exceptions for floating behavior are applied to transient elements like dialogs, allowing them to bypass tiling and position freely atop the layout.[43] User controls emphasize keyboard-driven operation for speed and precision, such as bindings like Mod4+Enter to spawn a new terminal or sequences to cycle focus, resize splits, or toggle layouts. Support for tagging systems or multiple workspaces enables grouping windows into virtual desktops, extending organization across multi-monitor environments without disrupting the primary tiling.[43] These managers enhance productivity by eliminating manual resizing and overlap management, keeping content fully visible and navigable via shortcuts, which suits intensive tasks like coding or document handling. Drawbacks include reduced flexibility for scenarios demanding free-form overlaps, such as graphical editing where windows may need independent layering.[44] Variants distinguish between static tilings, which adhere to fixed ratios and predefined divisions irrespective of window dynamics, and adaptive tilings that adjust sizes on the fly using application-provided hints for optimal fit.[42]Dynamic Window Managers
Dynamic window managers are a category of tiling window managers that incorporate adaptive layouts, allowing real-time adjustments to window arrangements in response to user interactions or predefined rules, often blending tiling with floating or stacking modes for flexibility.[14] Unlike purely static tiling systems, they build on tiling as a foundational mode but emphasize dynamic reconfiguration to optimize screen space without manual repositioning for every change.[45] These managers typically operate within the X11 environment, intercepting window requests via substructure redirection to enforce layouts while supporting multiple paradigms simultaneously.[14] The core of their adaptive behavior lies in layouts that evolve based on events such as window creation, focus shifts, or user gestures, using algorithms to split or reorganize screen areas on-the-fly.[14] For instance, in dwm, windows can switch between tiled (master-stack split), monocle (full maximization), and floating modes, with the manager automatically adjusting to the current set of open applications and tasks.[45] Similarly, i3 employs a tree-based structure where containers can dynamically split horizontally or vertically, adapting to workspace assignments across multiple monitors without fixed grids.[7] bspwm further exemplifies this through binary space partitioning, where insertion points and ratios adjust via modes like longest-side or spiral, responding to new windows or resizes in real time.[46] Such adaptations often incorporate scriptable rules or AI-like heuristics to prioritize workflow efficiency, such as enlarging focused windows or grouping related applications.[14] Rule-based systems enable precise control by matching window properties—such as class, instance, or title—to specific behaviors, allowing client-side decorations and automated placement without overriding all windows uniformly.[14] In i3, rules can float terminals or tile browsers based on their class, using an inter-process communication (IPC) interface to query and apply matches dynamically.[7] bspwm achieves this via shell scripts in bspwmrc, where matchers assign windows to desktops, states (e.g., floating or sticky), or padding, integrating with external tools like sxhkd for gesture-based triggers.[46] These systems leverage standards like Extended Window Manager Hints (EWMH) for interoperability, where properties such as _NET_WM_WINDOW_TYPE dictate treatment (e.g., docks or dialogs always floating).[47] Extensibility is a hallmark, often through plugin architectures, socket interfaces, or source recompilation, enabling custom transitions, animations, or policy engines tailored to user needs.[14] dwm, for example, requires editing C source code to add features like tag-based grouping or status bars, ensuring lightweight performance.[45] i3's IPC supports scripting in any language for event-driven extensions, such as automated animations on focus changes.[7] bspwm uses a socket protocol (via bspc) for third-party integrations, allowing policy engines to handle complex rules or visual effects.[46] Power users favor dynamic window managers for their balance of automation and manual control, particularly in minimalistic setups where efficiency trumps visual flair.[14] They excel in developer workflows, multi-monitor environments, or keyboard-centric navigation, as seen in i3 variants with gaps for aesthetic spacing or bspwm's scriptable panels.[7][46] This adaptability reduces context-switching overhead, making them ideal for tasks requiring frequent window juggling without mouse dependency.[45] Dynamic window managers emerged in the 2000s as extensions of earlier tiling concepts, incorporating EWMH for better compatibility with desktop environments and applications.[14][47] Influenced by predecessors like wmii, they prioritized standards compliance to enable seamless integration, evolving from rigid tilers to hybrid systems by the mid-2000s.[14]Compositing Window Managers
Compositing window managers render application windows to off-screen buffers rather than directly to the display, allowing the manager to combine these buffers into a final scene using techniques such as alpha blending and geometric transformations. This process typically involves redirecting window contents to pixmaps via extensions like XComposite, where the server stores hierarchical window data off-screen, and the compositor manually updates the visible parent window by compositing the redirected contents.[48] The Damage extension complements this by notifying the compositor of changes in window regions, enabling efficient partial updates without redrawing unchanged areas.[48] This off-screen rendering enables advanced visual effects, including window transparency through alpha channel blending, drop shadows generated by rendering semi-transparent overlays, and smooth animations such as fading or wobbling transitions between window states. By avoiding direct writes to the screen buffer, compositing also prevents screen tearing, as the final composited frame is swapped atomically to the display. These effects rely on hardware acceleration, often via OpenGL interfaces like GLX for X11 or EGL for broader compatibility, where window pixmaps are bound as textures for GPU-accelerated blending and transformation.[48][49] Compositing models differ between client-side and server-side approaches. In server-side compositing, prevalent in traditional X11 setups, the window manager intercepts all rendering through server extensions and performs the composition centrally, which simplifies coordination but can introduce latency for complex scenes. Client-side compositing, more common in hybrid modern systems, delegates initial rendering to individual applications (often using their own GPU buffers), with the compositor assembling these pre-rendered surfaces; this reduces server load but requires standardized protocols for buffer sharing. Wayland adopts a native server-side model where the compositor inherently manages all surface composition without separate extensions.[50][51] While compositing enhances visual fidelity and interactivity, it incurs performance trade-offs, including increased memory usage for off-screen buffers and higher CPU/GPU overhead for blending operations, particularly with transparency or numerous windows. However, integration with Direct Rendering Infrastructure (DRI) mitigates this by leveraging GPU acceleration, often yielding smoother performance than software-only rendering in non-compositing environments. The XComposite extension, introduced in 2004, standardized this for X11 by providing redirection and overlay mechanisms, whereas Wayland embeds compositing as a core protocol feature from its inception in 2008.[48][51]Implementations
X11-Based Window Managers
X11-based window managers are software components designed to manage the placement, appearance, and behavior of windows within the X Window System, a foundational display server protocol primarily used in Unix-like operating systems. These managers handle tasks such as drawing window decorations, responding to user input for resizing and moving windows, and enforcing standards like the Extended Window Manager Hints (EWMH) and Inter-Client Communication Conventions Manual (ICCCM) for interoperability with applications. Developed since the late 1980s, they form the backbone of graphical user interfaces in many Linux and BSD distributions, offering a range of paradigms from simple stacking to advanced tiling, often prioritizing lightweight resource usage and extensibility. One of the earliest and most foundational X11 window managers is twm, released in 1989 as part of X11R4, which supplanted previous managers like uwm to become the default for the X Window System.[52] As a lightweight stacking window manager, twm provides basic features including title bars, shaped windows, icon management, and simple menus accessible via mouse bindings, all implemented using the low-level Xlib library without heavier widget toolkits. Its minimal design, with a small codebase focused on core functionality, makes it suitable for resource-constrained environments, and it remains available in minimal installations of modern Linux distributions for legacy compatibility or basic setups.[52] Released in 2009, i3 represents a popular modern tiling window manager for X11, emphasizing manual control and efficiency for power users.[43] It automatically arranges windows in non-overlapping layouts using split containers that support recursive horizontal or vertical divisions, while allowing users to toggle individual windows to a floating mode for manual positioning and resizing.[43] A key feature is its Inter-Process Communication (IPC) interface via Unix sockets, enabling scripting in any language to dynamically control layouts, workspaces, and behaviors through commands likei3-msg.[43] i3 also supports configurable gaps—spaces between windows (inner gaps) or along screen edges (outer gaps)—introduced in version 4.22, enhancing visual separation without compromising its tiling philosophy.[43]
Openbox, first released on September 18, 2002, is a stacking window manager renowned for its standards compliance and integration into lightweight desktop environments.[53] It fully adheres to EWMH and ICCCM protocols, ensuring seamless interaction with applications expecting standard window hints for tasks like focus management and virtual desktops.[54] Designed to be highly configurable yet resource-efficient, Openbox draws minimal decorations and supports keyboard-driven operations, making it ideal for older hardware or minimal setups.[54] It serves as the default window manager for LXDE, a lightweight desktop environment, where it handles window operations while integrating with panels and file managers for a complete yet unobtrusive interface.[54]
Awesome, with its initial stable release of version 3.0 on September 18, 2008, is a dynamic tiling window manager that combines automated layout algorithms with extensive customization.[55] It uses a tag-based system instead of traditional workspaces, allowing windows to appear on multiple tags and supporting simultaneous views of several tags for flexible multitasking.[8] Configuration and extensions are handled through Lua scripting, providing a powerful API for defining custom layouts, such as spiral or floating arrangements, and creating widgets for system monitoring or notifications.[8] This scripting capability enables users to tailor behaviors like window snapping or tag transitions, making Awesome adaptable for developers seeking a programmable environment on X11.[8]
X11-based window managers were widely used in Linux and BSD ecosystems during the 2010s and early 2020s, but their prevalence has decreased with the adoption of Wayland as the primary protocol by mid-decade. They continue to power custom and lightweight desktop setups due to their maturity and compatibility with existing software. However, they face growing challenges from the rise of Wayland, including legacy protocol limitations that complicate security, multi-monitor support, and performance in modern hardware environments. This transition encourages future-proofing efforts, such as compatibility layers, to ease migration for users reliant on X11 tools.