Inter-Client Communication Conventions Manual
The Inter-Client Communication Conventions Manual (ICCCM) is a foundational specification for the X Window System that outlines voluntary conventions for inter-client communication among applications sharing a common X server, enabling cooperative behaviors in data exchange, window management, and resource allocation without mandating a specific user interface.[1] Developed collaboratively by the X Consortium's wmtalk working group over more than two years, the ICCCM originated as a draft in February 1988 during the X11 Release 2 development cycle and progressed through public review in 1989.[1] Version 1.0 was released in July 1989 alongside X11 Release 4, followed by Version 1.1 in September 1991 with X11 Release 5, and culminating in Version 2.0 in April 1994 for X11 Release 6, which introduced enhancements like improved session management support and fixes to earlier semantic ambiguities while preserving backward compatibility.[1] Edited initially by David Rosenthal and later by Stuart W. Marks, the manual emphasizes minimal required behaviors to promote timely adoption and interoperability among X clients.[1] Central to the ICCCM are mechanisms for peer-to-peer data transfer via selections (such as PRIMARY for pointer selections, SECONDARY for secondary selections, and CLIPBOARD for copy-paste operations) and cut buffers (using properties like CUT_BUFFER0 through CUT_BUFFER7 for simpler, legacy data storage).[1] It also details client interactions with window managers, including standard window properties (e.g., WM_NAME for titles, WM_HINTS for size and position preferences, and WM_PROTOCOLS for protocols like WM_DELETE_WINDOW) and state transitions such as Normal (mapped and visible), Iconic (iconified), and Withdrawn (unmapped without iconification).[1] Additional conventions address session management for state saving and restoration, shared resource handling (including input focus models like Passive and Globally Active, pointer grabs, and colormap installations), and device color characterization to standardize conversions between color spaces like XYZ and RGB.[1] These guidelines ensure robust, predictable behavior in multi-client X environments, influencing window manager implementations and application development to this day.[1]Development and History
Origins in X Window System
In the mid-1980s, the X Window System was designed primarily to provide low-level mechanisms for graphics and input handling, deliberately avoiding specifications for user interfaces or most inter-application communication to promote flexibility and portability across diverse hardware and operating systems.[2] This approach, while enabling rapid adoption during Project Athena at MIT starting in 1984, soon revealed significant challenges as the number of X-based applications grew; without standardized conventions, clients exhibited incompatible behaviors, such as inconsistent window management interactions and resource sharing, leading to fragmented user experiences and interoperability issues among applications from different developers.[3] To mitigate these problems, the X Consortium established the wmtalk working group in 1987, comprising experts focused on resolving window management and inter-client communication deficiencies in the evolving X ecosystem.[4] The group conducted extensive discussions over more than two years, highlighting the necessity for voluntary conventions that extended beyond the core X protocol's primitives to foster cooperative behaviors among clients, window managers, and other components.[2] Key early contributors included David Rosenthal, who served as the primary architect, and Stuart W. Marks, the editor, alongside participants like Bob Scheifler, Phil Karlton, and Ellis Cohen, who emphasized upward compatibility and minimal disruption to existing implementations during refinements at forums such as the January 1988 MIT X Conference and the 1988 Summer USENIX.[2] The culmination of these efforts was the initial draft of the Inter-Client Communication Conventions Manual, dated February 25, 1988, and distributed alongside the X11R2 release to promote basic compatibility guidelines for future client development.[2] This draft, explicitly labeled as subject to change, targeted essential areas like client-to-window manager signaling while prioritizing conceptual frameworks over rigid mandates, setting the stage for broader adoption within the X community.[3]Versions and Revisions
The development of the Inter-Client Communication Conventions Manual (ICCCM) involved several iterative drafts and releases by the MIT X Consortium, beginning with preliminary versions in 1988 and culminating in formalized standards integrated into X Window System releases.[1] An initial draft was distributed on February 25, 1988, with X Version 11 Release 2 (X11R2), serving as a preliminary document subject to significant changes.[1] This was followed by the July 27, 1988, Consortium Review Draft, which introduced key incompatibilities with the earlier draft, including disallowing the None property in ConvertSelection requests, renaming INCREMENTAL and INDIRECT protocols to INCR and MULTIPLE, updating the CLIPBOARD protocol, reducing the values in WM_HINTS.initial_state, and removing x, y, width, and height fields from WM_NORMAL_HINTS while adding base fields and win_gravity.[1] Public review drafts emerged in early 1989, incorporating further revisions such as replacing the messages field in WM_HINTS with WM_PROTOCOLS, introducing WM_COLORMAP_WINDOWS (replacing the less reliable WM_COLORMAPS), removing the pseudoroot concept, adding the WM_DELETE_WINDOW protocol, and updating RGB_COLOR_MAP conventions; these changes aimed to resolve ambiguities but created additional incompatibilities, particularly in colormap handling and session management semantics.[1] Version 1.0 of the ICCCM was released in July 1989 by the X Consortium, primarily featuring editorial fixes and minor clarifications, such as adding a section on input grabs, specifying the use of TARGETS and ClientMessage events for iconification, and requiring border-width inclusion in synthetic ConfigureNotify events, though it retained some incompatibilities from prior drafts like changes to property handling.[1] Version 1.1 followed in September 1991, published alongside X11 Release 5 (X11R5), and included minor semantic adjustments, notably the addition of a Device Color Characterization section, clarification of NULL as a valid property type, and references to Compound Text encoding, ensuring broader compatibility while addressing edge cases in protocol usage.[1] The push for Version 2.0 began with a public review draft in December 1993, developed over two years by the X Consortium's wmtalk working group to enhance the document's facilities and readability.[1] The final Version 2.0 was released in April 1994 with X11 Release 6 (X11R6), introducing new features like client-initiated colormap installation, revising the PIXMAP target, updating session management protocols, renaming VisibleHint to UrgencyHint, and prohibiting CurrentTime in WM_TAKE_FOCUS requests; it also fixed longstanding ambiguities from earlier versions, such as in selection protocols and window state changes, while maintaining upward compatibility where feasible and documenting exceptions in an appendix.[1] Incompatibilities across versions, including shifts in property semantics and protocol behaviors, are detailed in the ICCCM's Appendix A, advising implementers to check for backward compatibility modes.[1] These releases were officially published by the X Consortium as standards integral to the X11 ecosystem, influencing client and window manager implementations thereafter.[1]Purpose and Background
Objectives of the ICCCM
The Inter-Client Communication Conventions Manual (ICCCM) was developed to establish a set of standardized protocols enabling reliable inter-client communication within the X Window System, without requiring modifications to the underlying X protocol itself.[1] This approach aligns with the core design philosophy of X Version 11, which emphasizes specifying mechanisms rather than policies to allow flexibility in implementation.[1] By focusing on protocol-level operations, the ICCCM ensures that clients can interact seamlessly, expressed in terms that permit communication even across clients written in different programming languages.[3] A key objective was to promote interoperability among diverse X11 clients, window managers, and session managers, thereby minimizing the reliance on ad-hoc, application-specific workarounds that could fragment the ecosystem.[5] In the multi-vendor environment of the 1980s X ecosystem, this standardization aimed to foster a "good citizen" model where clients coexist harmoniously, reducing compatibility issues and enhancing overall system reliability.[3] The conventions were intentionally minimal, avoiding enforcement of any particular user interface to accommodate varied developer preferences while ensuring predictable behavior.[3] The ICCCM also sought to support user expectations by providing consistent frameworks for essential interactions, such as window manipulation, data exchange, and resource sharing, without dictating specific policies.[1] This focus on user-centric reliability helps maintain intuitive experiences across different applications and environments.[5] Finally, the manual emphasized forward compatibility and minimal assumptions about implementation details, reserving protocol values for future extensions and ensuring upward compatibility with prior drafts to allow evolution without breaking existing systems.[3] This design principle supports long-term adaptability in the X11 architecture.[1]Scope and Coverage
The Inter-Client Communication Conventions Manual (ICCCM) delineates a focused scope within the X Window System, standardizing inter-client interactions to promote interoperability without prescribing comprehensive policies. It primarily covers peer-to-peer data exchange mechanisms, such as selections (e.g., PRIMARY, SECONDARY, and CLIPBOARD) and cut buffers, which enable clients to share information directly. Additionally, it addresses client-to-window manager communication through conventions for managing top-level windows, including properties like WM_NAME and WM_HINTS, as well as state transitions such as Normal, Iconic, and Withdrawn states. The manual also encompasses session management protocols for preserving client state across sessions and guidelines for handling shared resources, including input focus, pointer grabs, colormaps, and keyboard mappings.[1] Explicitly excluded from the ICCCM's coverage are core X protocol extensions, low-level graphics primitives, and interactions in non-X environments, as the manual adheres to an explicit design goal of specifying mechanisms rather than policies. These exclusions ensure the document remains a lightweight set of conventions tailored to X Version 11's protocol-level operations, avoiding overlap with foundational protocol definitions or higher-level toolkits.[1] In the ICCCM, "conventions" are defined as non-mandatory but recommended practices, expressed solely in terms of protocol operations to foster robustness and interoperability among clients written in various languages, without relying on specific library interfaces like those in Xlib. This approach complements other X standards, such as the X Toolkit Intrinsics (Xt), by focusing on inter-client protocol behaviors rather than widget-level abstractions or user interface policies, thereby preventing domain overlap. Version 2.0 of the ICCCM expands these conventions slightly to address evolving needs in session management and resource handling.[1]Core Conventions
Peer-to-Peer Communication
The Inter-Client Communication Conventions Manual (ICCCM) establishes peer-to-peer communication between X11 clients through the selection mechanism, allowing direct, asynchronous data exchange independent of window manager intervention.[6] This approach enables clients to share diverse data types, such as text or images, by designating temporary ownership of selection atoms and handling conversion requests via X protocol events.[6] To ensure interoperability, clients are required to support only three predefined selections: PRIMARY, SECONDARY, and CLIPBOARD.[7] The PRIMARY selection functions as the default for communicating a single argument to applications, commonly facilitating middle-mouse-button paste operations in text-based interfaces.[7] The SECONDARY selection supports secondary arguments or temporary preservation of the PRIMARY selection during multi-step interactions.[7] The CLIPBOARD selection is reserved for explicit cut-and-paste operations, often coordinated by a dedicated clipboard manager client to maintain persistence across applications.[7] Ownership of a selection is asserted by a client using theXSetSelectionOwner request with a valid timestamp, and the current owner can be queried by any client via XGetSelectionOwner.[8] A requesting client initiates data transfer by issuing XConvertSelection, specifying the selection atom, target format (e.g., STRING or PIXMAP), and a property name on one of its own windows to receive the converted data.[8] The owner then converts the selection to the requested target, stores the result as the specified property on the requestor's window, and notifies completion or failure using XSendSelectionNotify to generate a SelectionNotify event.[9]
Support for multiple data types is facilitated by special targets: TARGETS returns a list of supported formats, while MULTIPLE allows a single request to convert to several targets simultaneously, with results stored in multiple properties.[7] All transfers operate asynchronously; the requestor polls for the SelectionNotify event and retrieves data via XGetProperty, after which it must delete the property using XDeleteProperty or XGetProperty with the delete option to acknowledge receipt and free resources.[8] For large datasets exceeding the X server's MaxRequestSize limit, the INCR protocol enables incremental transfer: the owner initially sets an INCR property with an estimated byte length, the requestor deletes it to begin, and the owner appends data chunks (each under the size limit) via successive property updates, signaling completion with a zero-length property that the requestor deletes upon retrieval.[10]
Selection owners bear primary responsibilities for timely responses, processing SelectionRequest events by converting and delivering data without undue delay, as prolonged waits can disrupt user interactions.[9] Requestors, in turn, must monitor events diligently and delete properties promptly to avoid resource leaks, though the ICCCM imposes no fixed timeouts, relying instead on the inherent asynchrony of the X event queue.[8]
As a legacy complement to selections, the ICCCM defines cut buffers for simple text exchanges, comprising eight fixed properties on the root window of screen zero: CUT_BUFFER0 through CUT_BUFFER7, each of type STRING and format 8 bits per item.[11] Clients store text by appending to these properties with XChangeProperty (using PropModeAppend for multi-line support) and retrieve primarily from CUT_BUFFER0 via XGetProperty, though any buffer is accessible; this mechanism prioritizes backward compatibility over the flexibility of selections.[11]
Client-to-Window Manager Communication
The Inter-Client Communication Conventions Manual (ICCCM) establishes standardized protocols for X11 clients to communicate with window managers, enabling consistent management of top-level windows' lifecycle, appearance, and behavior.[2] Clients achieve this primarily through X Window System properties set on top-level windows and by responding to events generated by the window manager.[2] These conventions ensure that window managers can reliably handle tasks such as resizing, iconification, and focus management without requiring proprietary extensions.[2] Central to this communication are specific window properties that clients must set to provide essential information. The WM_NAME property, a text property of format 8, contains an uninterpreted string representing the window's title, typically displayed in the title bar or border.[2] Similarly, the WM_ICON_NAME property, also a text property of format 8, supplies a string for the window's icon label when iconified.[2] The WM_NORMAL_HINTS property, of type WM_SIZE_HINTS and format 32, includes flags and values for size and position constraints in the normal state, such as minimum and maximum dimensions (min_width, max_height), preferred size increments, and aspect ratio limits; relevant flags include USPosition (bit 0) for user-specified position and PSize (bit 3) for program-specified size.[2] The WM_HINTS property, of type WM_HINTS and format 32, conveys additional behavioral hints, including initial_state (1 for NormalState or 3 for IconicState), input focus model (e.g., bit 0 for input allowed), icon position (icon_x, icon_y), and references to an icon pixmap or window.[2] Finally, the WM_PROTOCOLS property, an atom list of format 32, enumerates protocols the client supports, such as WM_DELETE_WINDOW, allowing the window manager to request actions like window deletion via synthetic events.[2] Window states are managed through the WM_STATE property, of type WM_STATE and format 32, which stores the current state value (0 for WithdrawnState, 1 for NormalState, or 3 for IconicState) along with the icon window ID if applicable.[2] In the NormalState, the window is viewable and fully managed by the window manager.[2] The IconicState indicates the window is unmapped and represented by an icon, with the icon itself becoming viewable.[2] The WithdrawnState means the window is unmapped and unmanaged, often used initially or when the client wishes to hide it without deletion.[2] Transitions between states, such as iconification, are initiated by the window manager sending a synthetic ClientMessage event with the WM_CHANGE_STATE atom and the target state in data, to which compliant clients must respond by unmapping or mapping the window as appropriate.[2] Clients perform key actions to facilitate management, starting with creating a top-level window as a child of the root window with override_redirect set to False, placing it initially in WithdrawnState until the window manager reparents or maps it.[2] For reparenting, where the window manager inserts an intervening frame window, clients receive a ReparentNotify event and must adjust event handling accordingly, with the option to reparent back to the root to withdraw the window.[2] Resizing and moving are guided by hints in WM_NORMAL_HINTS, where clients use ConfigureWindow requests with root-relative coordinates but defer actual changes to the window manager's synthetic ConfigureNotify events, ensuring they do not override management.[2] Icon geometry is specified via WM_HINTS fields like icon_x, icon_y, and icon_size hints from the WM_ICON_SIZE property, which defines preferred icon dimensions (minimum, maximum width/height) to standardize icon appearance across managers.[2] Window managers respond to client requests and state changes by generating synthetic events, particularly ClientMessage events sent to the client window, and the relevant protocol atom in the message_type field.[2] For instance, to invoke a protocol like WM_DELETE_WINDOW, the manager sends a ClientMessage with WM_PROTOCOLS in message_type and the specific atom in data, prompting the client to perform the action (e.g., close gracefully) rather than forcing unmapping.[2] These mechanisms ensure protocol compliance and smooth interaction without direct client-window manager coupling.[2]Advanced Features
Session Management
The Inter-Client Communication Conventions Manual (ICCCM) outlines conventions for managing the lifecycle of X Window System sessions, enabling clients and session managers to coordinate startup, shutdown, and state preservation without disrupting ongoing interactions. This framework integrates with the X Session Management Protocol (XSMP), which provides the underlying mechanism for session managers to instruct clients on saving and restoring their states across sessions.[1][12] Clients that support session management must register with the session manager to participate in these processes, ensuring that user sessions can be reliably terminated and restarted.[13] Client registration begins with the establishment of key window properties on the client leader window, a designated top-level window that represents the entire client application. The WM_CLIENT_MACHINE property, of type TEXT, specifies the name of the machine running the client, aiding the session manager in identifying and restarting the application on the appropriate host.[1] Upon connecting to the session manager via the SESSION_MANAGER environment variable, the client invokes the RegisterClient message in XSMP, providing a previous client-ID if restarting from a saved state; the session manager responds with a unique SM_CLIENT_ID property of type STRING, encoded in ISO 8859-1, which must be set on the client leader.[14] Additionally, the WM_CLIENT_LEADER property, of type WINDOW, identifies the leader window itself, and all top-level non-transient windows must reference this leader to associate them with the session.[13] An optional WM_WINDOW_ROLE property, also of type STRING, allows clients to assign unique identifiers to specific windows within the application, facilitating precise state restoration.[1] Before modifying these properties, clients must withdraw their top-level windows to prevent interference.[13] Interactions between clients and session managers occur through XSMP callbacks and ICCCM-defined protocols, primarily for state preservation during checkpoints. When the session manager initiates a save operation, it sends a SaveYourself message to the client, specifying parameters such as the checkpoint type (global, local, or both), whether it signals a shutdown, interaction style (none, errors only, or any), and whether it is a fast checkpoint.[15] In response, ICCCM-compliant clients implement the WM_SAVE_YOURSELF protocol by processing a ClientMessage event on their windows, prompting them to save their current state—such as user data, window positions, and configurations—and store restart information in properties like WM_COMMAND (a LISTofSTRING containing the command line for restarting the client).[16] Upon completion, the client sends a SaveYourselfDone message indicating success or failure, and may enter a withdrawn state by unmapping its windows and synthesizing UnmapNotify events to inform the window manager.[15] For complex saves, clients can request a second phase via SaveYourselfPhase2Request, allowing additional time for state capture.[17] Window managers play a coordinating role in session management, acting as clients themselves by registering with the session manager and obtaining their own SM_CLIENT_ID.[18] They relay session manager requests to managed clients without accessing or altering client-specific data, preserving properties like WM_STATE (indicating normal, iconic, or withdrawn states), window geometries, and stacking orders during checkpoints.[19] In the second checkpoint phase, triggered by the window manager's SaveYourselfPhase2Request, it saves layout information for all relevant windows before signaling completion to the session manager.[20] This ensures that the window manager can restore the desktop environment accurately upon restart, mapping windows back to their saved states while respecting client-provided roles and leaders.[18] During session shutdown, the session manager broadcasts a Die message to all registered clients after the save phase, prompting them to terminate gracefully by closing their connection and sending a ConnectionClosed reply.[21] Clients in withdrawn states during this sequence avoid unnecessary resource cleanup, as their windows are already unmapped, allowing the session manager to proceed with termination.[16] If shutdown is cancelled, a ShutdownCancelled message instructs clients to resume operations and potentially re-save state if needed.[22] On restart, clients reconnect using their saved SM_CLIENT_ID and properties, remapping windows to recreate the prior session layout under the window manager's coordination.[23] This process maintains session integrity, with the window manager ensuring that restored windows inherit their original properties, such as basic window attributes briefly referenced in client-to-window manager communications.[18]Shared Resources and Input Handling
The Inter-Client Communication Conventions Manual (ICCCM) establishes conventions for coordinating access to shared X11 resources, particularly input focus, pointer and keyboard events, colormaps, and keyboard mappings, to ensure interoperability among multiple clients without conflicts. These rules prevent race conditions and promote predictable behavior in multi-client environments, where clients must respect the window manager's role in resource arbitration.[1] ICCCM defines four input focus models for clients to indicate their focus preferences via theinput field in the WM_HINTS property and the presence or absence of the WM_TAKE_FOCUS client message protocol atom. In the No Input model, clients set the input field to False and omit WM_TAKE_FOCUS, signaling they do not accept focus (e.g., monitoring tools like xload). The Passive model sets input to True without WM_TAKE_FOCUS, allowing focus only when explicitly directed by the window manager. Locally Active clients set input to True and include WM_TAKE_FOCUS to manage focus within their subwindows, such as in applications with internal navigation. Globally Active clients set input to False but include WM_TAKE_FOCUS for focus across multiple windows, like scroll bars in editors. Clients using SetInputFocus requests must specify revert_to Parent to return focus to the parent window upon release. These models dictate event delivery: for instance, EnterNotify and LeaveNotify events are generated based on pointer movement relative to the focus window, with NotifyPointer mode for pointer-relative focus.[24][24]
Pointer grabs and button/keyboard event handling follow strict ownership rules to avoid interference. Clients must establish button or key grabs only on windows they own, using GrabButton or GrabKey requests, and should release grabs promptly after use to minimize blocking other clients. Window managers enforce synchronous grabs in GrabModeSync and use AllowEvents with ReplayPointer or ReplayKeyboard modes to forward events to the grabbing client while permitting replays for verification. For keyboard events, clients receive KeyPress and KeyRelease only if they hold focus or have an active grab; otherwise, events propagate to the root window or focused client. Button events similarly route via pointer focus, with conventions prohibiting passive grabs on non-owned windows to prevent event theft. These mechanisms ensure that shared input devices like the pointer and keyboard deliver events predictably, with window states (e.g., withdrawn or iconic) briefly influencing focus eligibility as per client-to-window manager protocols.[25][26]
Colormap management conventions address shared visual resources by delegating installation to the window manager while allowing clients to request changes. Clients notify the window manager of colormap needs by setting the WM_COLORMAP_WINDOWS property, listing subwindows requiring distinct colormaps in priority order (highest first), and must not issue InstallColormap or UninstallColormap requests except when holding an active pointer grab to avoid races. Upon a colormap change, clients send a ClientMessage event with the WM_COLORMAP_NOTIFY atom to the window manager, which then installs the specified colormap for the affected window. Race conditions may arise if the window manager's InstallColormap executes concurrently with the client's notification, but the window manager mitigates this by monitoring property changes and prioritizing the list. The root window provides a default colormap that clients inherit unless overridden, ensuring basic color availability without explicit requests. These rules promote efficient sharing of limited colormap resources in pseudo-color visuals.[27][27]
Keyboard mapping and modifier key assignments are coordinated to prevent conflicts over shared input interpretations. Clients must avoid ChangeKeyboardMapping requests unless responding to actual hardware changes, instead relying on the server's initial mapping or user tools like xmodmap for adjustments. For modifier keys, clients assign KeySyms to unused modifier bits (e.g., Mod1 through Mod5) only if available, querying via GetModifierMapping to identify free slots. Non-reclaimable modifiers, such as those bound to fixed hardware functions, cannot be automatically reassigned by clients; users must manually reconfigure them using xmodmap to free bits for application-specific needs. This convention ensures that keyboard events, including modifier combinations in KeyPress deliveries, remain consistent across clients without one overriding another's mappings.[28][29]
Implementations
Compliant Window Managers
The Inter-Client Communication Conventions Manual (ICCCM) defines compliance for window managers through adherence to specific protocols for client-to-window manager interactions, including proper handling of window properties such as WM_HINTS, WM_PROTOCOLS, and WM_STATE, as well as support for client messages, transient windows, and state transitions without violating core conventions.[1] Full compliance requires implementing these elements to ensure interoperability with X clients, while partial compliance may involve basic support but extensions or omissions in advanced features.[30] Historical implementations of ICCCM-compliant window managers emerged in the late 1980s and early 1990s alongside the X Window System's evolution. The Tab Window Manager (twm), released in 1989 as part of X11R4, was designed with full ICCCM compliance in mind, serving as the default window manager for early X distributions and supporting essential properties and protocols for window manipulation and iconification.[31] The Motif Window Manager (mwm), introduced in the early 1990s with the Motif toolkit, achieved robust ICCCM compliance, enabling seamless integration with Motif-based applications through standardized decoration and session handling.[32] Similarly, the Open Look Window Manager (olwm), developed by Sun Microsystems from 1988 to 1994, was explicitly ICCCM-compliant, incorporating the XView toolkit to provide consistent behavior for Open Look interfaces under X11R4 and later releases.[33] The FVWM (Feeble Virtual Window Manager), first released in 1993, offered extensible ICCCM compliance via its configuration file system, allowing customization while maintaining support for 3D visuals, virtual desktops, and protocol adherence.[34] In modern contexts, several window managers continue to prioritize ICCCM compliance, often extending it with the Extended Window Manager Hints (EWMH) for enhanced functionality. Openbox, developed in the 2000s, is a lightweight stacking window manager that strictly follows ICCCM standards, emphasizing minimal resource use and full support for client hints and protocols in desktop environments like LXDE.[35] KWin, the default window manager for KDE Plasma since the late 1990s, provides full ICCCM and EWMH compliance, including root window properties, application window states, and protocols for features like maximization and virtual desktops.[36] Mutter, powering GNOME since 2007, maintains a compliant core implementation of ICCCM requirements, covering window manager protocols, transient handling, and state management. For tiling window managers, i3 (released in 2010) offers basic ICCCM compliance, supporting essential properties and client messages for window placement and focus while prioritizing manual tiling workflows.[37] Some window managers exhibit partial ICCCM compliance, extending beyond the standard with custom features that may not fully align with all protocols. Enlightenment (versions E16 from 2000 and E17 from 2008 onward) builds on ICCCM foundations but introduces advanced theming and compositing that occasionally deviates from strict property handling, focusing on Enlightenment Foundation Libraries (EFL) integration.[38] Awesome, a Lua-scripted tiling window manager since 2007, provides partial compliance by supporting core client classes and rules per ICCCM guidelines but emphasizes dynamic tiling and scripting over exhaustive protocol coverage.[39]Compliance Testing
Verifying adherence to the Inter-Client Communication Conventions Manual (ICCCM) in X11 applications and window managers typically involves a combination of manual inspection tools and automated testing frameworks to ensure proper handling of window properties, events, and protocol interactions. Developers commonly use command-line utilities such asxprop to query and display window properties, allowing direct examination of ICCCM-required atoms like WM_STATE or WM_PROTOCOLS to confirm their correct format, type, and values.[40] Similarly, xwininfo provides detailed information about window geometry, hierarchy, and attributes, which is essential for validating aspects of client-to-window manager communication, such as transient window relationships or size hints. These tools enable developers to select specific windows interactively or by ID and output raw data for analysis, facilitating spot checks during development without requiring full protocol traces.
For more systematic verification, automated test suites from X.org, such as the X Test Suite (XTS), offer property validation and protocol simulation capabilities tailored to X11 client-server interactions. XTS includes modules that simulate client behaviors, send requests like GetProperty or ChangeProperty, and assert expected responses, helping to catch deviations in ICCCM conventions like selection ownership or event propagation.[41] These tests can be run in a controlled environment to replay sequences of X protocol messages, ensuring that applications respond correctly to scenarios outlined in the ICCCM, such as colormap installation or focus changes.
Testing ICCCM compliance often reveals common pitfalls, particularly race conditions in selection mechanisms where multiple clients attempt simultaneous ownership transfers, potentially leading to lost data if timestamps are not handled precisely.[2] Focus event ordering can also fail in edge cases, such as when SetInputFocus is applied to unmapped windows, resulting in incorrect notification sequences that violate the input focus model.[2] State transitions present another challenge, where delays in processing WM_TAKE_FOCUS or window state changes can disrupt session management, emphasizing the need for robust event loop implementations to maintain synchronization.
Community resources on freedesktop.org provide practical aids for self-assessment, including scripts and informal checklists derived from developer discussions that guide verification of ICCCM properties and behaviors.[42] These materials, often shared via mailing lists or tool repositories, complement core utilities by offering example test harnesses for common scenarios, enabling developers to build custom validation routines.