5. Session Management

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.

5.1. Client Support for Session Management

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: All top-level, non-transient 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: 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:

5.2. Window Manager Support for Session Management

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.
<^>

Christophe Tronche