On startup, each client that should identify the settings window by calling XGetSelectionOwner() for the _XSETTINGS_S[N] selection and select for notification on the settings window by calling XSelectInput() with a mask of StructureNotifyMask|PropertyChangeMask.

To prevent race conditions a client MUST grab the server while performing these operations using XGrabServer().

If there is no owner of the _XSETTINGS_S[N] selection, the client can determine when an owner is established by listening for client messages sent to root window of the screen with type MANAGER. (See section 2.8, Manager Selections of the ICCCM.) The format of this message is:

 event-mask:   StructureNotify
 event:        ClientMessage
 type:         MANAGER
 format:       32
 data[0]:      timestamp
 data[1]:      _XSETTINGS_S[N] (atom)
 data[2]:      New owner of the selection
 data[3]:      0 (reserved)
    

The client can then proceed to read contents of the _XSETTINGS_SETTINGS property from the settings window and interpret according to the information in the "_XSETTINGS_SETTINGS Format" section of this document.

Clients must trap X errors when reading the _XSETTING_SETTINGS property because it is possible that the selection window may be destroyed at any time.

When the client is notified that the settings window has been destroyed or discovers that the selection window has been destroyed, it should reset all settings to their default values and then proceed as on initial startup. [ See rational section ]

When a client receives a PropertyChangeNotify event for the window it should reread the _XSETTING_SETTINGS property. It can use the 'serial' field to tell what fields have been changed. The client must parse the entire property and read in all new values before taking action on changed settings such as notifying listeners for those settings to avoid using a mix of old and new data.