Hubbry Logo
Window managerWindow managerMain
Open search
Window manager
Community hub
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.
Window manager
Window manager
Window manager
View on Wikipedia
from Wikipedia
Layers of the graphical user interface:
Under X, the window manager and the display server are two distinct programs; but under Wayland, the function of both is handled by the Wayland compositor.
Typical elements of a window. The window decoration is either drawn by the window manager or by the client. The drawing of the content is the task of the client.
Under X11, when the window manager is not running, the window decorations are missing for most windows.

A window manager is system software that controls the placement and appearance of windows within a windowing system in a graphical user interface.[1] Most window managers are designed to help provide a desktop environment. They work in conjunction with the underlying graphical system that provides required functionality—support for graphics hardware, pointing devices, and a keyboard—and are often written and created using a widget toolkit.

Few window managers are designed with a clear distinction between the windowing system and the window manager. Every graphical user interface based on a windows metaphor has some form of window management. In practice, the elements of this functionality vary greatly.[2] Elements usually associated with window managers allow the user to open, close, minimize, maximize, move, resize, and keep track of running windows, including window decorators. Many window managers also come with various utilities and features such as task bars, program launchers, docks to facilitate halving or quartering windows on screen, workspaces for grouping windows, desktop icons, wallpaper, an ability to keep select windows in foreground, the ability to "roll up" windows to show only their title bars, to cascade windows, to stack windows into a grid, to group windows of the same program in the task bar in order to save space, and optional multi-row taskbars.[3][4][5][6]

History

[edit]
Main article: History of the graphical user interface

In 1973, the Xerox Alto became the first computer shipped with a working WIMP GUI. It used a stacking window manager that allowed overlapping windows.[7] However, this was so far ahead of its time that its design paradigm would not become widely adopted until more than a decade later. While it is unclear if Microsoft Windows contains designs copied from Apple's classic Mac OS, it is clear that neither was the first to produce a GUI using stacking windows. In the early 1980s, the Xerox Star, successor to the Alto, used tiling for most main application windows, and used overlapping only for dialogue boxes, removing most of the need for stacking.[8]

The classic Mac OS was one of the earliest commercially successful examples of a GUI that used a sort of stacking window management via QuickDraw. Its successor, macOS, uses a somewhat more advanced window manager that has supported compositing since Mac OS X 10.0, and was updated in Mac OS X 10.2 to support hardware accelerated compositing via the Quartz Compositor.[9]

GEM 1.1, from Digital Research, was a operating environment that included a stacking window manager, allowing all windows to overlap. It was released in the early 1980s.[10] GEM is famous for having been included as the main GUI used on the Atari ST, which ran Atari TOS, and was also a popular GUI for MS-DOS prior to the widespread use of Microsoft Windows. As a result of a lawsuit by Apple, Digital Research was forced to remove the stacking capabilities in GEM 2.0, making its window manager a tiling window manager.[11]

During the mid-1980s, Amiga OS contained an early example of a compositing window manager called Intuition (one of the low-level libraries of AmigaOS, which was present in Amiga system ROMs), capable of recognizing which windows or portions of them were covered, and which windows were in the foreground and fully visible, so it could draw only parts of the screen that required refresh. Additionally, Intuition supported compositing. Applications could first request a region of memory outside the current display region for use as bitmap. The Amiga windowing system would then use a series of bit blits using the system's hardware blitter to build a composite of these applications' bitmaps, along with buttons and sliders, in display memory, without requiring these applications to redraw any of their bitmaps.

In 1988, Presentation Manager became the default shell in OS/2, which, in its first version, only used a command line interface (CLI). IBM and Microsoft designed OS/2 as a successor to DOS and Windows for DOS. After the success of Windows 3.10, however, Microsoft abandoned the project in favor of Windows. After that, the Microsoft project for a future OS/2 version 3 became Windows NT, and IBM made a complete redesign of the shell of OS/2, substituting the Presentation Manager of OS/2 1.x for the object-oriented Workplace Shell that made its debut in OS/2 2.0.[12]

Examples

[edit]

X window managers

[edit]
Main article: X window manager

On systems using the X Window System, there is a clear distinction between the window manager and the windowing system. Strictly speaking, an X window manager does not directly interact with video hardware, mice, or keyboards – that is the responsibility of the display server.

A desktop environment typically integrates a default window manager: for instance GNOME 2 uses Metacity, while KDE Plasma Workspaces uses KWin. But X Window System's modular design allows the user to switch to a different window manager: for instance Compiz (a 3D compositing manager) may be used if 3D effects are desired, while Sawfish and awesome instead offer exacting window control. Some components of different window managers can even be mixed and matched; for example, the window decorations from KWin can be used with the desktop and dock components of GNOME.

X window managers also have the ability to re-parent applications, meaning that, while initially all applications are adopted by the root window (essentially the whole screen), an application started within the root window can be adopted by (i.e., put inside of) another window. Window managers under the X window system adopt applications from the root window and re-parent them to apply window decorations (for example, adding a title bar). Re-parenting can also be used to add the contents of one window to another. For example, a flash player application can be re-parented to a browser window, and can appear to the user as supposedly being part of that program. Re-parenting window managers can therefore arrange one or more programs within the same window, and can easily combine tiling and stacking in various ways.

Further information: Re-parenting window manager

Microsoft Windows

[edit]

Microsoft Windows has provided an integrated stacking window manager since Windows 2.0; Windows Vista introduced the compositing Desktop Window Manager (dwm.exe) as an optional hardware-accelerated alternative. In Windows, since GDI is part of the kernel,[13] the role of the window manager is tightly coupled with the kernel's graphical subsystems and is largely non-replaceable, although third-party utilities can be used to simulate a tiling window manager on top of such systems. Window management on Windows can also be enhanced with third-party tools such as WindowBlinds, Resource Hacker, and SmartWindows. Since Windows 8, the Direct3D-based Desktop Window Manager can no longer be disabled.[14] It can only be restarted with the hotkey combination Ctrl+Shift+Win+B.[15]

Windows Explorer (explorer.exe) is used by default as the shell in modern Windows systems to provide a taskbar and file manager, along with many functions of a window manager; aspects of Windows can be modified through the provided configuration utilities, modifying the Windows Registry or with 3rd party tools, such as WindowBlinds or Resource Hacker.

A complete X Windows Server, allowing the use of window managers ported from the unixoid world can also be provided for Microsoft Windows through Cygwin/X even in multiwindow mode (and by other X Window System implementations). Thereby, it is easily possible to e.g. have X Window System client programs running either in the same Cygwin environment on the same machine, or on a Linux, BSD Unix etc. system via the network, and only their GUI being displayed and usable on top of the Microsoft Windows environment.

Note that Microsoft and X Window System use different terms to describe similar concepts. For example, there is rarely any mention of the term window manager by Microsoft because it is integrated and non-replaceable, and distinct from the shell.[clarification needed][16] The Windows Shell is analogous to the desktop environment concept in other graphical user interface systems.

ChromeOS

[edit]

Since 2021 ChromeOS is shipped with its own window manager called Ash.[17] Chromium and ash share common codebase.[17] In the past one could run it by using google-chrome --open-ash on any compatible systems.

Types

[edit]

Window managers are often divided into three or more classes, which describe how windows are drawn and updated.

Compositing window managers

[edit]
Main article: Compositing window manager

Compositing window managers let all windows be created and drawn separately and then put together and displayed in various 2D and 3D environments. The most advanced compositing window managers allow for a great deal of variety in interface look and feel, and for the presence of advanced 2D and 3D visual effects.

Stacking window managers

[edit]
Main article: Stacking window manager

All window managers that have overlapping windows and are not compositing window managers are stacking window managers, although it is possible that not all use the same methods. Stacking window managers allow windows to overlap by drawing background windows first, which is referred to as the painter's algorithm. Changes sometimes require that all windows be re-stacked or repainted, which usually involves redrawing every window. However, to bring a background window to the front usually only requires that one window be redrawn, since background windows may have bits of other windows painted over them, effectively erasing the areas that are covered.

Tiling window manager

[edit]
Main article: Tiling window manager

Tiling window managers paint all windows on-screen by placing them side by side or above and below each other, so that no window ever covers another. Microsoft Windows 1.0 used tiling, and a variety of tiling window managers for X are available, such as i3, awesome, and dwm.

Dynamic window manager

[edit]
Main article: Dynamic window manager

Dynamic window managers can dynamically switch between tiling or floating window layout. A variety of dynamic window managers for X are available.

Features and facilities of window managers

[edit]
Autohide
An autohide facility enables menubars to disappear when the pointer is moved away from the edge of the screen.
Borders
A border is a window decoration component provided by some window managers, that appears around the active window. Some window managers may also display a border around background windows.
Context menu
Some window managers provide a context menu that appears when an alternative click event is applied to a desktop component.
Example of a context menu
Example of a context menu
Desktop wallpaper
Some window managers provide a desktop wallpaper facility that displays a background picture in the root window.
Focus stealing
Focus stealing is a facility some window managers provide. It allows an application not in focus to suddenly gain focus and steal user input intended for the previously focused application.
Iconification
An iconification facility lets users minimize running applications to a desktop icon or taskpanel icon.
Joined windows
Some window managers provide a joined windows facility that lets user join application window frames together.
Keyboard equivalents
Some window managers provide keyboard equivalents that enables the keyboard to replicate mouse functionality.
Menubar
A menubar provides the facility to launch programs via a menu and may contain additional facilities including a start button, a taskbar, and a system tray.
Menu panel
A menu panel a component of some window managers that provides the facility to launch programs using a menu. A menu panel is similar to a menubar, but appears as a floating panel, rather than a horizontal or vertical bar.
The menu panel may contain additional facilities including a start button, a task panel, and a system tray.
Mouse focus
The mouse focus model determines how the pointing device affects the input focus within the window manager. The focus model determine which component of the graphical user interface is currently selected to receive input as the pointer is moved around the screen.
Mouse warping
Mouse warping is a facility that centres the pointer on the current application as it is made active.
Multiple desktops
A window manager may provide a multiple desktops facility. This enables switching between several root window desktops. This prevents clutter of the root window, because applications can run on different desktops.
Pager
Some window managers provide a pager tool that provides the facility to switch between multiple desktops. The pager may appear as an onscreen window or as a gadget in the taskbar or taskpanel.
Plugins
Some window managers have a modular construction that enables plug-in modules to provide features as required.
Rollup
A rollup facility enables windows to appear as just a titlebar on the desktop.
Root Menu
Some window managers provide a root menu, which appears when the root window or desktop background is touched.
Shortcuts
Some window managers provide a shortcut facility that lets users place icons on the root window that access specific programs or facilities.
Tabbed windows
Some window managers provide a tabbed windows facility that groups applications together in common frames.
Task switching
The window manager may provide various task switching facilities that let the user change the currently focused application, including:
  • Changing the mouse focus using a pointing device
  • Keyboard task switching facilities (for example, by pressing Alt-Tab)
  • Clicking on the task in a taskbar or taskpanel
Taskbar
Some window managers provide a taskbar that shows running applications. The taskbar may show all applications that are running including those that have been minimized, and may provide the facility to switch focus between them. The taskbar may be incorporated into a menubar on some window managers.
Task panel
A task panel is similar to a taskbar, but appears as a floating panel, rather than a horizontal or vertical bar.
Start button
A start button is a desktop widget that provides a menu of programs that can be launched. The start button is typically placed on a menubar at the bottom of the screen.
Notification area
A notification Area is used to display icons for system and program features that have no desktop window. It contains mainly icons to indicate status information and notifications such as arrival of a new mail message. Some systems may also show a clock in the Notification Area.
Title bars
A title bar is a window decoration component some window managers provide at the top of each window. The titlebar is typically used to display the name of the application, or the name of the open document, and may provide title bar buttons for minimizing, maximizing, closing or rolling up of application windows.
Title bar buttons
Title bar buttons are included in the title bar of some window managers, and provide the facility to minimize, maximize, rollup or close application windows. Some window managers may display the titlebar buttons in the taskbar or task panel, rather than in a titlebar.
Virtual desktop
A virtual desktop (also called a scrolling desktop) is a facility some window managers provided that lets the desktop be larger than the actual screen

Windows navigation

[edit]

An active window is the currently focused window in the current window manager. Different window managers indicate the currently-active window in different ways and allow the user to switch between windows in different ways. For example, in Microsoft Windows, if both Notepad and Microsoft Paint are open, clicking in the Notepad window will cause that window to become active. In Windows, the active window is indicated by having a different colored title bar. Clicking is not the only way of selecting an active window, however: some window managers (such as FVWM) make the window under the mouse pointer active—simply moving the mouse is sufficient to switch windows; a click is not needed.

Window managers often provide a way to select the active window using the keyboard as an alternative to the mouse. One typical key combination is Alt+Tab, used by Windows and KDE (by default, though this is user-configurable); another is apple key-tilde, used by Macintosh. Pressing the appropriate key combination typically cycles through all visible windows in some order, though other actions are possible.

Many, though not all, window managers provide a region of the screen containing some kind of visual control (often a button) for each window on the screen. Each button typically contains the title of the window and may also contain an icon. This area of the screen generally provides some kind of visual indication of which window is active—for example, the active window's button may appear “pushed in”. It is also usually possible to switch the active window by clicking on the appropriate button. In Microsoft Windows, this area of the screen is called the taskbar; in Apple Macintosh systems this area of the screen is called the dock.

The active window may not always lie in front of all other windows on the screen. The active window is simply the window to which keys typed on the keyboard are sent; it may be visually obscured by other windows. This is especially true in window managers which do not require a click to change active windows: FVWM, for example, makes active the window under the mouse cursor but does not change its Z-order (the order in which windows appear, measured from background to foreground). Instead, it is necessary to click on the border of the window to bring it to the foreground. There are also situations in click-to-focus window managers such as Microsoft Windows where the active window may be obscured; however, this is much less common.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Window manager

View on Grokipedia
from Grokipedia
A window manager is that controls the placement, appearance, and behavior of windows within a of a (GUI). 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. In systems like operating environments, window managers function as clients of the underlying , such as the , which provides basic graphics and input handling but delegates layout control to the manager. Similarly, in Windows, the () serves as a manager, enabling like transparency and animations while overseeing window rendering. In Apple's macOS, the Aqua interface uses an integrated window manager for window and effects. 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. 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. The (1981) commercialized these ideas with a full widget set, including scrollbars and menus, influencing subsequent GUIs. By the mid-1980s, the —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. Contemporary window managers are categorized by their layout philosophies: stacking managers permit overlapping windows with manual positioning (e.g., or ), tiling managers automatically arrange non-overlapping windows to maximize screen use (e.g., i3 or Awesome), and dynamic or variants blend these with effects like blurring. They often integrate into desktop environments, such as 's Mutter or KDE's , which extend management with workspaces, theming, and accessibility features. Proposed innovations as of 2023, including adaptive "mosaic" modes and app-specific sizing metadata in , aim to address longstanding challenges like visual clutter and hidden windows in multi-tasking scenarios, though core implementation remains ongoing as of 2025.

Fundamentals

Definition and Purpose

A (WM) is that controls the placement, appearance, size, and movement of windows within a (GUI), acting as an intermediary between applications and the display server. In this role, it operates as a client program in systems like the , managing top-level windows without direct hardware access. 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. It mediates competition for screen space among applications by interpreting client hints on preferred sizes and positions, ensuring efficient without applications needing to manage overlaps or input routing directly. Unlike full desktop environments, which incorporate additional elements like panels, file managers, and theming systems, a window manager focuses solely on window lifecycle and , allowing modular integration into broader GUI ecosystems. 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. 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. This design emerged in the 1980s as graphical user interfaces proliferated on displays, addressing the chaos of unmanaged overlapping windows in early systems like the developed at MIT. 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.

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. 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 . 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. 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, 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. Similarly, KDE Plasma uses to manage windows, enabling seamless integration with the DE's theming and widget systems. 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 (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. 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. 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. 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 actions, are routed by the display server to appropriate clients, bypassing the window manager except for focus mediation. Theming, involving sets and color schemes, resides in the DE's domain to maintain coherence across applications, leaving window managers to apply only frame-specific decorations.

Historical Development

Origins in Early Computing

The origins of window managers trace back to pioneering research in interactive computing during the , where early systems introduced concepts of multiple display regions to enhance user interaction on limited screens. Ivan Sutherland's , 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 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 , advanced these ideas with tiled windows that could split screens horizontally or vertically, supporting cross-window editing and navigation via the newly invented . These vector-display-based systems laid the groundwork for overlapping and dynamic window concepts, though they operated without 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 , 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 , introduced in 1984 at MIT as a client-server , fundamentally separated the display server from window management responsibilities, enabling flexible window managers to run as clients atop the server. 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 (), 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. The 1990s saw proliferation of alternatives, including the (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. 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 implementations. The launch of in 1998 integrated the KDE Window Manager (kwm), a stacking manager with customizable decorations and effects, while , released in 1999, initially paired with —a Lisp-configurable stacking manager emphasizing extensibility and smooth animations—to provide a cohesive . These integrations marked a shift toward user-friendly, themeable environments amid growing Unix desktop adoption. The 2000s brought a boom, driven by hardware advancements and the demand for . , introduced in 2002 as '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. Compiz, released in early 2006, pioneered open-source 3D on X11 using 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. 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. The XWayland compatibility layer, introduced around 2016, ensures seamless support for legacy X11 applications during this transition. 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. 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. By the 2020s, trends emphasize , input modernity, and portability. Wayland's architecture enhances through per-client sandboxing and elimination of X11's global access vulnerabilities, as seen in 50's Wayland-only mandate in 2025, which isolates applications to prevent screen scraping and unauthorized input injection. Compositors increasingly support touch and gesture interactions, with and on Wayland enabling window manipulation and swipe gestures since the mid-2010s. Cross-platform frameworks like , which powers applications such as , leverage native window managers (e.g., via Chromium's Wayland backend) for consistent behavior across , Windows, and macOS, though challenges like resizing persist without explicit configuration.

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. 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. 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. 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, the client as its child to intercept input and expose events for handling borders, titlebars, and controls. 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. 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. 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. However, it requires manual user intervention for placement and resizing, often leading to screen clutter and occlusion as windows pile up without automatic organization. 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. Historically, stacking window managers dominated early graphical interfaces, serving as the foundation for implementations like , 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. 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.

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 over manual placement, these managers aim to streamline workflows, particularly for users focused on keyboard and multi-tasking. The core layout principles revolve around dividing the screen into geometric regions using techniques like (BSP), where windows serve as leaves in a full structure, and the desktop is recursively partitioned into subspaces. 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. 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. 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 environments without disrupting the primary tiling. 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. Variants distinguish between static tilings, which adhere to fixed ratios and predefined divisions irrespective of window dynamics, and adaptive tilings that adjust sizes using application-provided hints for optimal fit.

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. 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. These managers typically operate within the X11 environment, intercepting window requests via substructure redirection to enforce layouts while supporting multiple paradigms simultaneously. 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. 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. 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. 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. Such adaptations often incorporate scriptable rules or AI-like heuristics to prioritize workflow efficiency, such as enlarging focused windows or grouping related applications. 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. In i3, rules can float terminals or tile browsers based on their class, using an (IPC) interface to query and apply matches dynamically. 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. 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). Extensibility is a hallmark, often through plugin architectures, socket interfaces, or source recompilation, enabling custom transitions, animations, or policy engines tailored to user needs. dwm, for example, requires editing C source code to add features like tag-based grouping or status bars, ensuring lightweight performance. i3's IPC supports scripting in any language for event-driven extensions, such as automated animations on focus changes. bspwm uses a socket protocol (via bspc) for third-party integrations, allowing policy engines to handle complex rules or visual effects. Power users favor dynamic window managers for their balance of automation and manual control, particularly in minimalistic setups where efficiency trumps visual flair. 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. This adaptability reduces context-switching overhead, making them ideal for tasks requiring frequent window juggling without mouse dependency. Dynamic window managers emerged in the 2000s as extensions of earlier tiling concepts, incorporating EWMH for better compatibility with desktop environments and applications. Influenced by predecessors like wmii, they prioritized standards compliance to enable seamless integration, evolving from rigid tilers to hybrid systems by the mid-2000s.

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 the redirected contents. The extension complements this by notifying the compositor of changes in window regions, enabling efficient partial updates without redrawing unchanged areas. 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, also prevents , as the final composited frame is swapped atomically to the display. These effects rely on , often via interfaces like for X11 or EGL for broader compatibility, where window pixmaps are bound as textures for GPU-accelerated blending and transformation. 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. While 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 (DRI) mitigates this by leveraging GPU acceleration, often yielding smoother performance than software-only rendering in non- environments. The XComposite extension, introduced in , standardized this for X11 by providing redirection and overlay mechanisms, whereas Wayland embeds as a core protocol feature from its inception in 2008.

Implementations

X11-Based Window Managers

X11-based window managers are software components designed to manage the placement, appearance, and behavior of windows within the , a foundational display server protocol primarily used in 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 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 , released in 1989 as part of X11R4, which supplanted previous managers like uwm to become the default for the . As a lightweight , 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 distributions for legacy compatibility or basic setups. Released in 2009, i3 represents a popular modern for X11, emphasizing manual control and efficiency for power users. 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. A key feature is its (IPC) interface via Unix sockets, enabling scripting in any language to dynamically control layouts, workspaces, and behaviors through commands like i3-msg. 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. Openbox, first released on September 18, 2002, is a renowned for its standards compliance and integration into lightweight s. 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. 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. It serves as the default window manager for , a lightweight , where it handles window operations while integrating with panels and file managers for a complete yet unobtrusive interface. Awesome, with its initial stable release of version 3.0 on , 2008, is a dynamic that combines automated layout algorithms with extensive customization. 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. Configuration and extensions are handled through scripting, providing a powerful for defining custom layouts, such as spiral or floating arrangements, and creating widgets for system monitoring or notifications. 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. X11-based window managers were widely used in and BSD ecosystems during the and early , but their prevalence has decreased with the adoption of Wayland as the primary protocol by mid-decade. They continue to power custom and 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 , 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.

Wayland Compositors

Wayland compositors integrate window management directly with display server functionality, leveraging the protocol's design for enhanced security and performance in modern environments. Unlike traditional X11 window managers, these compositors handle rendering and input locally on clients, reducing overhead and enabling smoother interactions. This prioritizes isolation between applications, mitigating risks like unauthorized screen captures or input interception. Weston, the reference Wayland compositor, was first released in 2012 alongside Wayland 1.0. It provides a minimal, fast suitable for testing the protocol's core features, including support for multiple display outputs through kernel mode setting (KMS). For demonstrations, Weston includes clients like weston-simple-mipool, which showcases efficient for image rendering via multiple buffer pools. As a lightweight environment, Weston serves primarily as a development tool rather than a full desktop solution. Sway, launched in 2016, functions as a tiling compositor fully compatible with i3 configurations, allowing seamless migration from X11-based setups. Its keyboard-centric design promotes efficient workflow through automatic arrangement in non-overlapping layouts, minimizing dependency. Built on the wlroots library, Sway abstracts low-level Wayland backend tasks, enabling robust protocol implementation while maintaining simplicity and modularity. This makes it popular among users seeking a lightweight, customizable alternative to traditional desktops. Mutter, GNOME's core compositor originally introduced in 2002, gained initial Wayland support in 2016 with GNOME 3.20, evolving into a full Wayland display server thereafter. It employs dynamic window management, adapting layouts based on user actions and supporting gestures for tasks like window resizing or switching. The overview mode, a key feature, presents all open windows in a grid for intuitive navigation, integrated with for a cohesive experience. Mutter's design emphasizes accessibility and fluidity, handling compositing effects like animations without compromising performance. KWin, KDE Plasma's window manager, introduced Wayland sessions in 2017 with Plasma 5.10, supporting a hybrid approach that combines stacking and paradigms. It manages virtual desktops for organizing workflows across multiple spaces and applies configurable effects, such as blur or wobble, to enhance visual feedback during interactions. Under Wayland, KWin leverages client-side rendering for these effects, ensuring compatibility with diverse hardware while maintaining KDE's focus on customization. Compared to X11, Wayland compositors enable direct client rendering, where applications submit buffers straight to the GPU, significantly lowering latency in input-response cycles. Security is bolstered by the absence of global input grabs, as each client receives only its intended events, preventing malicious interceptions common in X11. These improvements address longstanding issues in aging display architectures. Wayland adoption accelerated with 21.10 in 2021, which set on Wayland as the default session, paving the way for broader integration. By 2025, major distributions like , , and have made Wayland the primary protocol, with X11 relegated to legacy support via XWayland for compatibility with older applications. This shift reflects maturing ecosystem support and hardware optimizations.

Proprietary Systems

Proprietary window managers are integral components of closed-source operating systems, where they are tightly integrated with the OS kernel and layers, often making them non-replaceable by users without significant modifications. These systems prioritize seamless , , and ecosystem-specific optimizations over , contrasting with open-source alternatives that emphasize user configurability. In Microsoft Windows, the shell process Explorer.exe has served as the primary window manager since in 1995, implementing a stacking model with deep integration into the for window switching and desktop management. This evolved significantly with the introduction of the (DWM) in in 2007, which added hardware-accelerated compositing using to enable the Aero visual style, including transparent windows and live thumbnails. Recent updates, such as Snap Layouts in released in 2021, incorporate tiling-inspired arrangements while maintaining the stacking paradigm, allowing users to snap windows into predefined grids for multitasking. Apple's macOS employs the Quartz Compositor, introduced in 2001 with and the Aqua interface, as its core windowing system, supporting dynamic stacking with smooth transitions and . Mission Control, added in 2011 with Mac OS X Lion, enhances this by providing an overview of all open windows and virtual desktops (Spaces), enabling quick navigation across multiple workspaces. Animations and layering are handled natively through Core Animation, a framework that leverages GPU for fluid user interactions without taxing the CPU. Google's Chrome OS utilizes the framework, launched in 2011, as a lightweight tailored for web-centric applications, managing window hierarchies and events in a resource-efficient manner. For integration with its subsystem, introduced via in 2018, Chrome OS employs the Wayland server to handle window management for Linux apps within the Aura shell, ensuring compatibility without disrupting the core desktop experience. In mobile contexts, though focused on desktop equivalents, Android's SurfaceFlinger—deployed since Android 1.0 in 2008—acts as the engine for layering application surfaces onto the display, optimized for touch interactions. Similarly, iOS's , originating with iPhone OS 1.0 in 2007, provides touch-optimized window layering for app icons and home screen management, emphasizing gesture-based over traditional desktop paradigms. These proprietary implementations exhibit tight coupling with their respective operating systems, rendering them less replaceable by users compared to open-source options, while ongoing updates like Snap Layouts demonstrate efforts to incorporate advanced layout features.

Core Features

Window Placement and Manipulation

Window placement strategies in window managers encompass manual user-initiated positioning through drag-and-drop operations, algorithmic methods such as centering newly opened windows on the primary screen to avoid overlap—for example, 48 defaults new windows to the screen center as of its release on March 19, 2025—and rule-based approaches that utilize application-provided hints to determine initial positions based on window type or role. The Inter-Client Communication Conventions Manual (ICCCM), a foundational standard for X11-based systems, specifies the WM_NORMAL_HINTS property, which includes flags like USPosition for user-specified coordinates and PPosition for program-requested positions, along with win_gravity values (e.g., NorthWest or Static) to define how the window frame positions relative to the client area during placement. The Extended Window Manager Hints (EWMH) protocol builds on this by introducing _NET_WM_WINDOW_TYPE atoms (e.g., _NET_WM_WINDOW_TYPE_DIALOG or _NET_WM_WINDOW_TYPE_DESKTOP), enabling window managers to apply tailored placement rules, such as positioning transient dialogs near their parent windows or restricting desktop backgrounds to non-overlapping areas. Window manipulation actions typically involve moving a window by dragging its title bar to a new location and resizing it by pulling on the edges or corners, with constraints often enforced via hints to respect minimum or maximum dimensions and resize increments. Additional features like snapping to a grid or screen edges streamline these operations; for instance, Microsoft's Aero Snap, introduced in in October 2009, automatically resizes and positions windows to half-screen or quarter-screen layouts when dragged to edges or corners. Multi-monitor support in window managers allows the desktop to extend across multiple displays, often with independent per-screen workspaces to isolate application groups, while addressing DPI scaling to prevent blurry rendering on high-density screens. Recent enhancements include KDE Plasma 6.4's lock screen elements appearing only on the focused screen with synced password input across displays, released on June 17, 2025. In X11 environments, the Resize and Rotate (RandR) extension facilitates dynamic multi-monitor configurations by enabling the addition, removal, and relative positioning of outputs to form a unified virtual screen. Wayland compositors natively handle per-monitor scaling and multi-display setups through protocol-defined outputs, improving consistency over X11's global scaling limitations. Windows systems support per-monitor DPI awareness, automatically adjusting UI element sizes and positions based on each display's resolution and density settings. State management capabilities enable users to minimize windows to a or for iconified representation (IconicState in ICCCM terms), maximize them to fill the available screen area, or switch to fullscreen mode that hides decorations and covers the entire display. Virtual desktops provide layering by assigning windows to separate numbered workspaces, allowing organization without closing applications; EWMH standardizes this with _NET_NUMBER_OF_DESKTOPS to set the total count and _NET_WM_DESKTOP to specify a window's assigned desktop (or -1 for all). KDE Plasma 6.4, released June 17, 2025, introduces support for different tile layouts per to enhance flexible organization. Core protocols underpin these features: the ICCCM establishes basic hints for positioning, sizing, and states like NormalState for visible windows, ensuring interoperability in X11. EWMH extends compatibility with advanced properties, including _NET_WM_STATE atoms such as _NET_WM_STATE_MAXIMIZED_VERT and _NET_WM_STATE_STICKY for windows that remain visible across all virtual desktops. Tiling window managers represent a specialized algorithmic variant, automatically arranging windows in non-overlapping layouts based on predefined rules.

User Navigation and Interaction

Users interact with window managers through various focus models that dictate how keyboard input is assigned to specific windows. The click-to-focus model requires explicit mouse clicks on a window to grant it focus, ensuring deliberate selection and commonly used in environments like KDE Plasma's KWin. In contrast, the focus-follows-mouse model automatically directs focus to the window beneath the mouse pointer upon hover, eliminating the need for clicks and facilitating fluid navigation in tiling setups such as i3. Sloppy focus serves as a variant of focus-follows-mouse, where focus shifts when the mouse enters a window but remains on the last focused window if the pointer moves over non-window areas like the desktop background, as implemented in KWin. Switching between windows relies on keyboard-driven techniques for efficient traversal. The combination cycles through open windows or applications in most recently used (MRU) order, prioritizing recently accessed items for quick return, a standard in where timestamps determine the sequence. Task switchers enhance this by displaying thumbnails or previews of windows, allowing visual selection, while configurable shortcuts like Super+Tab in or Mod+j/k/l/; in i3 enable directional cycling within the current workspace. These methods support both global application switching and per-workspace navigation, adapting to user preferences via configuration files. Window managers handle user inputs by intercepting mouse and keyboard events, particularly for decorations such as title bars and borders. In X11-based systems, the window manager receives these events through the X protocol, processing them to manage window raising, resizing, or closing without passing them to client applications unless intended. Modern implementations extend this to multi-touch gestures; for instance, macOS's Quartz Compositor supports four-finger swipes on trackpads to switch between full-screen apps or desktops, configurable in system settings. KDE Plasma 6.4 adds three-finger touchpad pinch gestures for zooming as of its June 17, 2025 release. Accessibility features integrate seamlessly into navigation to support diverse users. Screen readers like in leverage the Service Provider Interface (AT-SPI) to announce focus changes, window activations, and structural updates in real-time. High-contrast modes, available in and , amplify visual distinctions between elements like focused windows and backgrounds to aid low-vision users. Sticky keys functionality, enabled in both and , latches modifier keys (e.g., Ctrl or Alt) after a single press, enabling one-handed execution of shortcuts like for navigation. As of November 7, 2025, GTK applications support a reduced motion setting to provide alternative animations, reducing visual overload for users with vestibular sensitivities. Plasma 6.4 enhances keyboard navigation and screen reader usability as of June 17, 2025. Workspace navigation allows users to organize and traverse multiple virtual desktops efficiently. Keyboard shortcuts facilitate cycling through desktops, such as Mod+1-0 in i3 for direct jumps or Ctrl+Alt+Up/Down in for sequential movement. Overview grids provide a visual panorama; 's Activities Overview, introduced with 3.0 in April 2011, displays all open windows across workspaces in a searchable grid, activated via the Super key for rapid selection and switching.

Theming and Customization

Window managers offer extensive theming options to personalize the visual appearance of graphical interfaces, including window borders, title bars, and control buttons such as close or minimize icons. These elements are often governed by standards like the Extended Window Manager Hints (EWMH), which define protocols for window decorations and ensure interoperability between applications and window managers across desktop environments. Compliance with EWMH allows themes to specify properties like border widths, colors, and button layouts consistently, promoting a unified look without requiring application-specific modifications. Configuration of themes and behaviors typically occurs through multiple methods tailored to the window manager's design philosophy. Text-based configuration files, such as ~/.config/i3/config in the i3 window manager, enable precise control over theme variables like colors and fonts via declarative syntax. Graphical user interfaces, exemplified by KDE System Settings for the KWin window manager, provide intuitive panels for selecting and previewing themes without editing files manually; Plasma 6.4 adds a new Animations page for customizing visual effects as of June 17, 2025. For more dynamic setups, runtime scripting languages like Lua in Awesome WM allow users to load and modify themes programmatically, supporting modular extensions for real-time adjustments. Behavior customization extends beyond visuals to include keybind remapping and per-application rules, enabling users to tailor interactions for efficiency. Keybinds can be reassigned to trigger actions like window resizing or switching, often defined in configuration files for keyboard-driven workflows. Rule sets, such as i3's for_window directives, apply policies like always-on-top status or floating mode to specific applications based on criteria like window class or title, ensuring consistent handling across sessions. Extensions and plugins further enhance theming by integrating with toolkit ecosystems like and Qt, allowing color schemes and font rendering to align across diverse applications. For instance, Awesome WM's Lua-based modules facilitate plugin loading for advanced font configurations and theme transitions. Such integrations bridge gaps between window manager decorations and application UIs, maintaining visual coherence. KDE Plasma 6.4 darkens the Breeze Dark theme for better contrast and dims the desktop background during as of June 17, 2025. Cross-window manager portability is achieved through tools like LXAppearance, a desktop-independent GTK+ theme switcher that applies themes, icons, and fonts universally across stacking window managers without altering core configurations. This utility writes settings to standard locations like ~/.gtkrc-2.0, enabling seamless theme migration between environments such as and i3. Compositing window managers can leverage these themes to add effects like for enhanced visual depth.

References

  1. https://www.x.org/archive/X11R6.7.0/doc/X.7.html
  2. https://www.media.mit.edu/wearables/mithril/anduin/window_manager.html
  3. https://learn.microsoft.com/en-us/windows/win32/dwm/dwm-overview
  4. https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf
  5. https://www.cs.cmu.edu/~amulet/papers/uihistoryinteractions.pdf
  6. http://www.cs.cmu.edu/~bam/papers/WindowUITaxonomy.pdf
  7. https://i3wm.org/
  8. https://awesomewm.org/
  9. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/reference_guide/s2-x-clients-winmanagers
  10. https://wiki.gnome.org/Projects/Mutter
  11. https://kde.org/applications/kwin/
  12. https://blogs.gnome.org/tbernard/2023/07/26/rethinking-window-management/
  13. https://release.gnome.org/48/
  14. https://www.cs.ru.nl/bachelors-theses/2019/Max_van_Deurzen___4581903___The_anatomy_of_the_modern_window_manager_-_a_case_study_for_X_in_an_Agile_manner.pdf
  15. https://www.x.org/releases/current/doc/man/man7/X.7.xhtml
  16. https://wayland.freedesktop.org/faq.html
  17. https://stackoverflow.com/questions/42982963/what-is-the-difference-between-display-server-a-window-manager-and-a-composito
  18. https://x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
  19. https://www.tuxedocomputers.com/en/Whats-the-deal-with-X11-and-Wayland-_1.tuxedo
  20. https://kwin.kde.org/
  21. https://specifications.freedesktop.org/wm-spec/latest-single
  22. https://dev.to/sandheep_kumarpatro_1c48/beyond-the-basics-in-depth-look-at-linux-display-servers-window-managers-and-compositors-40bk
  23. https://askubuntu.com/questions/18078/what-is-the-difference-between-a-desktop-environment-and-a-window-manager
  24. https://dlab.epfl.ch/wikispeedia/wpcd/wp/x/X_Window_System.htm
  25. https://www.linux.org/threads/various-window-managers.10430/
  26. https://www.datagubbe.se/pickwm/
  27. https://wiki.archlinux.org/title/Window_manager
  28. https://help.ubuntu.com/community/Metacity
  29. http://www.linux-magazine.com/Online/Features/What-s-Taking-Wayland-So-Long
  30. https://arstechnica.com/gadgets/2016/12/fedora-25-review-the-best-linux-distro-of-2016-arrived-at-the-last-moment/
  31. https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/Wayland/
  32. https://www.osnews.com/story/11941/looking-at-windows-vistas-user-interface-aero/
  33. https://arstechnica.com/gadgets/2000/01/macos-x-gui/
  34. https://linuxsecurity.com/news/desktop-security/gnome-50-wayland-linux-security
  35. https://electronjs.org/docs/latest/tutorial/security
  36. https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
  37. https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html
  38. https://dl.acm.org/doi/10.1145/22627.22356
  39. https://www.researchgate.net/publication/299700031_An_Evaluation_of_Stacking_and_Tiling_Features_within_the_Traditional_Desktop_Metaphor
  40. https://www.x.org/archive/X11R7.6/doc/man/man1/twm.1.xhtml
  41. https://manpages.ubuntu.com/manpages/noble/man1/bspwm.1.html
  42. https://wiki.archlinux.org/title/Comparison_of_tiling_window_managers
  43. https://i3wm.org/docs/userguide.html
  44. https://itsfoss.com/tiling-window-manager/
  45. https://dwm.suckless.org/
  46. https://github.com/baskerville/bspwm
  47. https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html
  48. https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt
  49. https://blog.mecheye.net/2012/06/the-linux-graphics-stack/
  50. https://unix.stackexchange.com/questions/198627/difference-between-server-side-and-client-side-compositing-in-xorg
  51. https://wayland.freedesktop.org/architecture.html
  52. https://wiki.archlinux.org/title/Twm
  53. https://openbox.org/
  54. https://wiki.archlinux.org/title/Openbox
  55. https://awesomewm.org/releases/
  56. https://lwn.net/Articles/520832/
  57. https://wayland.pages.freedesktop.org/weston/
  58. https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/SD/WindowingSystems/WestonWayland.html
  59. https://github.com/swaywm/sway
  60. https://swaywm.org/
  61. https://mutter.gnome.org/
  62. https://bbs.archlinux.org/viewtopic.php?id=211147
  63. https://community.kde.org/KWin/Wayland
  64. https://www.cbtnuggets.com/blog/technology/networking/why-use-wayland-versus-x11
  65. https://www.abhik.xyz/concepts/linux/wayland-x11
  66. https://pieterbakker.com/linux-changes-in-2024-and-expectations-for-2025/
  67. https://developer.apple.com/documentation/quartzcore
  68. https://devblogs.microsoft.com/oldnewthing/20120102-00/?p=8743
  69. https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/april/aero-glass-create-special-effects-with-the-desktop-window-manager
  70. https://leopard-adc.pepas.com/documentation/MacOSX/Conceptual/OSX_Technology_Overview/OSX_Technology_Overview.pdf
  71. https://www.apple.com/newsroom/2011/06/06Mac-OS-X-Lion-With-250-New-Features-Available-in-July-From-Mac-App-Store/
  72. https://www.chromium.org/developers/design-documents/aura-desktop-window-manager/
  73. https://chromeos.dev/en/linux
  74. https://chromeos.dev/en/posts/integrating-steam-into-chromeos
  75. https://source.android.com/docs/core/graphics/surfaceflinger-windowmanager
  76. https://www.apple.com/newsroom/2007/01/09Apple-Reinvents-the-Phone-with-iPhone/
  77. https://tronche.com/gui/x/icccm/sec-4.html#WM_NORMAL_HINTS
  78. https://support.microsoft.com/en-us/windows/snap-your-windows-885a9b1e-a983-a3b1-16cd-c531795e6241
  79. https://blogs.windows.com/windows-insider/2015/06/04/arrange-your-windows-in-a-snap/
  80. https://blogs.kde.org/2025/06/02/revisiting-x11-vs-wayland-with-multiple-displays/
  81. https://kde.org/announcements/plasma/6/6.4.0/
  82. https://www.x.org/releases/X11R7.7/doc/randrproto/randrproto.txt
  83. https://tronche.com/gui/x/icccm/sec-4.html
  84. https://docs.kde.org/stable5/en/kwin/kcontrol/windowbehaviour/index.html
  85. https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6553
  86. https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/
  87. https://support.apple.com/en-us/102482
  88. https://wiki.gnome.org/Orca
  89. https://userbase.kde.org/System_Settings/Accessibility
  90. https://thisweek.gnome.org/posts/2025/11/twig-224
  91. https://www.youtube.com/watch?v=dMak0R_fE2g
  92. https://userbase.kde.org/System_Settings
  93. https://awesomewm.org/apidoc/documentation/05-awesomerc.md.html
  94. https://github.com/lxde/lxappearance
Add your contribution
Related Hubs
User Avatar
No comments yet.