X11 ICCCM Diagrams
X11 Inter-Client Communication Conventions Manual
The manual itself was written by X Consortium, and is not mine.
The purpose of these diagrams is to visually represent requirements from the manual, so they will be easier to implement. Any mistakes are mine, the manual is always right, except where noone else followed it either.
Currently I'm not aiming to include extensions or toolkit behaviors.
Why is this hard enough to need diagrams?
The protocol is both event based and stateful. It also involves multi-purpose data types, potential for network errors, user interactivity and other complex behavior.
Non-visual representations tend to focus on the stateful aspects or the event based ones, when it is the interaction between them that is most important. With visual representation, architecture decisions are less likely to be ad-hoc.
Atom
Details in ICCCM 1.2, including naming conventions.
Used for naming other objects. Can contain the name of a:
- Selection Name
- Selection Target (type)
- Property Name
- Property Type
- Font Property
- ClientMessage Type
Must be created ("InternAtom") before use. Some common ones are auto-created. Creation should be minimized for server resource reasons, since Atoms are permanent. Names of auto-created Atoms can be found in X11/Xatom.h
Selection
A selection, named by an Atom, is global to a server. It may contain data in any of many formats. Used often are the selections:
- PRIMARY
- SECONDARY
- CLIPBOARD
Logic: Selection Requested
Logic: Ownership Requested
Acquire Timestamp
If you have just received an event, use its timestamp.
Otherwise, append a 0-length string to a property of something, and use that timestamp.
Fail State
Pause and try again?
Die?
Interact with user?
OnEvent: SelectionRequest
Obsolete Client
Set property to target atom.
OnEvent: PropertyNotify
If we receive that this property has been deleted, we know the data has been accepted at the other end. This also is used in transferring multiple sections.
Regain Selection?
Is there a race condition here?
Unlikely as relinquishing selections doesn't require specific action on the part of the selection owner, which at this point may or may not know it is the owner.
Data: Last Timestamp
If previously the selection owner (frx. in clipboard manager), SelectionClear provided timestamp.
Clipboard Manager
Major actions refer to selection handling diagram at left.
Fail State (Counted)
The text actually says "or if you have received the same timestamp twice" for the branch I labeled simply as "2", yet this seems to lead to a silly.
Request Conversion TIMESTAMP
Property Append Method
- Send an append to a property, with nothing to append and a length of 0.
- Wait extremely selectively for the event this appending is supposed to cause.
- Gain from it the timestamp.
Does this event ever fail to come? Should the block be within a timeout?
Fail Fail State
Possible actions:
- Sleep N, try again
- Contact user
- Die
The INCR Complication
Incurred when the data to be copied is too long for single segments.
