DocsTable of Contents
This section contains some conventions for clients that participate in session management. See X Session Management Protocol for further details. Clients that do not support this protocol cannot expect their window state (e.g., WM_STATE, position, size, and stacking order) to be preserved across sessions.
Each session participant will obtain a unique client identifier (client-ID) from the session manager. The client must identify one top-level window as the "client leader." This window must be created by the client. It may be in any state, including the Withdrawn state. The client leader window must have a SM_CLIENT_ID property, which contains the client-ID obtained from the session management protocol. That property must:
Be of type STRING
Be of format 8
Contain the client-ID as a string of XPCS characters encoded using ISO 8859-1
All top-level, nontransient windows created by a client on the same display as the client leader must have a WM_CLIENT_LEADER property. This property contains a window ID that identifies the client leader window. The client leader window must have a WM_CLIENT_LEADER property containing its own window ID (i.e., the client leader window is pointing to itself). Transient windows need not have a WM_CLIENT_LEADER property if the client leader can be determined using the information in the WM_TRANSIENT_FOR property. The WM_CLIENT_LEADER property must:
Be of type WINDOW
Be of format 32
Contain the window ID of the client leader window
A client must withdraw all of its top-level windows on the same display before modifiying either the WM_CLIENT_LEADER or the SM_CLIENT_ID property of its client leader window.
It is necessary that other clients be able to uniquely identify a window (across sessions) among all windows related to the same client-ID. For example, a window manager can require this unique ID to restore geometry information from a previous session, or a workspace manager could use it to restore information about which windows are in which workspace. A client may optionally provide a WM_WINDOW_ROLE property to uniquely identify a window within the scope specified above. The combination of SM_CLIENT_ID and WM_WINDOW_ROLE can be used by other clients to uniquely identify a window across sessions.
If the WM_WINDOW_ROLE property is not specified on a top-level window, a client that needs to uniquely identify that window will try to use instead the values of WM_CLASS and WM_NAME. If a client has multiple windows with identical WM_CLASS and WM_NAME properties, then it should provide a WM_WINDOW_ROLE property.
The client must set the WM_WINDOW_ROLE property to a string that uniquely identifies that window among all windows that have the same client leader window. The property must:
Be of type STRING
Be of format 8
Contain a string restricted to the XPCS characters, encoded in ISO 8859-1
A window manager supporting session management must register with the session manager and obtain its own client-ID. The window manager should save and restore information such as the WM_STATE, the layout of windows on the screen, and their stacking order for every client window that has a valid SM_CLIENT_ID property (on itself, or on the window named by WM_CLIENT_LEADER) and that can be uniquely identified. Clients are allowed to change this state during the first phase of the session checkpoint process. Therefore, window managers should request a second checkpoint phase and save clients' state only during that phase.
The Inter-Client Exchange protocol (ICE) defined as of X11R6 specifies a generic communication framework, independent of the X server, for data exchange between arbitrary clients. ICE also defines a protocol for any two ICE clients who also have X connections to the same X server to locate (rendezvous with) each other.
This protocol, called the "ICE X Rendezvous" protocol, is defined in
the ICE specification, Appendix B,
and uses the property ICE_PROTOCOLS plus
ClientMessage
events. Refer to that specification for complete details.