1. The comment in the protocol specification for
InternAtom
that ISO Latin-1 encoding should be used is in the nature of a convention;
the server treats the string as a byte sequence.
2. At present, no part of the protocol requires requestors
to send events to the owner of a selection.
This restriction is imposed to prepare for possible future extensions.
3. The division between these two cases is a matter of judgement
on the part of the software developer.
4. This requirement is new in version 2.0, and in general, existing
clients do not conform to this requirement. To prevent these clients
from breaking, no existing targets should be extended to take
parameters until sufficient time has passed for clients to be updated.
Note that the MULTIPLE target was defined to take parameters in version
1.0 and its definition is not changing. There is thus no conformance
problem with MULTIPLE.
5. Earlier versions of this document erroneously specified that conversion of
the PIXMAP target return a property of type DRAWABLE instead of PIXMAP.
Implementors should be aware of this and may want to support the DRAWABLE
type as well to allow for compatibility with older clients.
6. The targets ENCAPSULATED_POSTSCRIPT and ENCAPSULATED_POSTSCRIPT_INTERCHANGE
are equivalent to the targets _ADOBE_EPS and _ADOBE_EPSI (respectively) that
appear in the selection targets registry. The _ADOBE_ targets are
deprecated, but clients are encouraged to continue to support them for
backward compatibility.
7. This definition is ambiguous, as the selection may be converted into any of
several targets which may return differing amounts of data. The requestor
has no way of knowing which, if any, of these targets corresponds to the
result of LENGTH. Clients are advised that no guarantees can be made about
the result of a conversion to LENGTH; its use is thus deprecated.
8. Note that this is different from STRING, where many byte values are
forbidden, and from COMPOUND_TEXT, where, for example, inserting the
sequence 27,\ 40,\ 66 (designate ASCII into GL) at the start does not alter
the meaning.
9. These properties were called INCREMENTAL in an earlier draft.
The protocol for using them has changed,
and so the name has changed to avoid confusion.
10. We use the notation data[n] to indicate the nth element
of the LISTofINT8, LISTofINT16, or LISTofINT32 in the data field of the
ClientMessage ,
according to the format field.
The list is indexed from zero.
11. This obsolete protocol was described in the July 27, 1988
draft of the ICCCM.
Windows using it can also be detected because their WM_HINTS properties are
four bytes longer than expected.
Window managers are free to support clients using the obsolete protocol
in a backwards compatibility mode.
12. Earlier versions of these conventions prohibited clients from
reading the WM_STATE property. Clients operating under the earlier
conventions used the technique of tracking
ReparentNotify
events to wait for the top-level window to be reparented back to the root
window. This is still a valid technique; however, it works only for
reparenting window managers, and the WM_STATE technique is to be preferred.
13. The type field of the
ClientMessage
event (called the message_type field by Xlib) should not be confused with
the code field of the event itself,
which will have the value 33
( ClientMessage ).
14. This is true even if the client set the backing-store attribute to
Always .
The backing-store attribute is a only a hint,
and the server may stop maintaining backing store contents at any time.
15. As a special case, clients not wishing to implement a selection
request may simply issue a
GetSelectionOwner
request on the appropriate WM_Sn selection. If this selection is owned,
clients may assume that the window manager complies with ICCCM version 2.0
or later.
16. This convention has changed since earlier drafts because of the introduction of the protocol in the next section. In the public review draft, there was ambiguity as to whether WM_SAVE_YOURSELF was a checkpoint or a shutdown facility. It is now unambiguously a checkpoint facility; if a shutdown facility is judged to be necessary, a separate WM_PROTOCOLS protocol will be developed and registered with the X Consortium.