[no subject]

  ---

> 4.1.2.5.  WM_CLASS Property
> 
> The WM_CLASS property (of type STRING without control char­
> acters) contains two consecutive null-terminated strings.
> These specify the Instance and Class names to be used by
> both the client and the window manager for looking up
> resources for the application or as identifying information.
> This property must be present when the window leaves the
> Withdrawn state and may be changed only while the window is
> in the Withdrawn state.  Window managers may examine the
> property only when they start up and when the window leaves
> the Withdrawn state, but there should be no need for a
> client to change its state dynamically.
> 
> The two strings, respectively, are:
> 
> ·   A string that names the particular instance of the
>     application to which the client that owns this window
>     belongs.  Resources that are specified by instance name
>     override any resources that are specified by class name.
>     Instance names can be specified by the user in an oper­
>     ating-system specific manner.  On POSIX-conformant sys­
>     tems, the following conventions are used:
> 
>     -    If "-name NAME" is given on the command line, NAME
>          is used as the instance name.
> 
>     -    Otherwise, if the environment variable
>          RESOURCE_NAME is set, its value will be used as the
>          instance name.
> 
>     -    Otherwise, the trailing part of the name used to
>          invoke the program (argv[0] stripped of any direc­
>          tory names) is used as the instance name.
> 
> ·   A string that names the general class of applications to
>     which the client that owns this window belongs.
>     Resources that are specified by class apply to all
>     applications that have the same class name.  Class names
>     are specified by the application writer.  Examples of
>     commonly used class names include: "Emacs", "XTerm",
>     "XClock", "XLoad", and so on.
> 
> Note that WM_CLASS strings are null-terminated and, thus,
> differ from the general conventions that STRING properties
> are null-separated.  This inconsistency is necessary for
> backwards compatibility.

As for the WM_WINDOW_ROLE, I never said anything about making it visible.
Nonetheless:

> 5.1.  Client Support for Session Management
>
>   . . .
>
> It is necessary that other clients be able to uniquely iden­
> tify 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


RTFM,
Gregory Merchan