X Window System core protocol: Difference between revisions

Revision as of 18:46, 17 September 2013

Revision as of 13:22, 29 September 2013

Line 165:

Atoms are 32-bit integers representing [[String (computing)|string]]s. The protocol designers introduced atoms because they represent strings in a short and fixed size:<ref name="icccm">[[David S. H. Rosenthal|David Rosenthal]]. [[Inter-Client Communication Conventions Manual]]. MIT X Consortium Standard, 1989</ref> while a string may be arbitrarily long, an atom is always a 32-bit integer. Atom brevity was exploited by mandating their use in the kinds of packets that are likely to be sent many times with the same strings; this results in a more efficient use of the network. The fixed size of atoms was exploited by specifying a fixed size for events, namely 32 bytes: fixed-size packets can contain atoms, while they cannot contain long strings.

Precisely, atoms are identifiers of strings stored in the server. They are similar to the identifiers of resources (Windows, Pixmaps, etc.) but differ from them in two ways. First, the identifiers of atoms are chosen by the server, not by the client. In other words, when a client requests the creation of a new atom, it only sends the server the string to be stored, not its identifier; this identifier is chosen by the server and sent back as a reply to the client. The second important difference between resources and atoms is that atoms are not associated with clients. Once created, an atom survives until the server quits or resets (this is not the default behavior of resources).

Atoms are identifiers and are therefore unique. However, an atom and a resource identifier can coincide. The string associated with an atom is called the ''atom name''. The name of an atom cannot be changed after creation, and no two atoms can have the same name. As a result, the name of an atom is commonly used to indicate the atom: “the atom <code>ABCD</code>” means, more precisely, “the atom whose associated string is <code>ABCD</code>.” or “the atom whose name is <code>ABCD</code>.” A client can request the creation of a new atom and can request for the atom (the identifier) of a given string. Some atoms are ''predefined'' (created by the server with given identifier and string).

Line 255:

{{main|Xlib}}

Most client programs communicate with the server via the [[Xlib]] client library. In particular, most clients use libraries such as [[Xaw]], [[Motif (widget toolkitsoftware)|Motif]], [[GTK+]], or [[Qt (toolkit)|Qt]] which in turn use Xlib for interacting with the server. The use of Xlib has the following effects:

# Xlib makes the client synchronous with respect to replies and events:

Line 265:

## the program asks for an event in the event queue (for example, by calling <code>XNextEvent</code>) and the call blocks (for example, <code>XNextEvent</code> blocks if the queue is empty.)

Higher-level libraries such as [[Intrinsics|Xt]] (which is in turn used by [[Xaw]] and [[Motif (widget toolkitsoftware)|Motif]]) allow the client program to specify the [[callback (computer science)|callback function]]s associated with some events; the library takes care of polling the event queue and calling the appropriate function when required; some events such as those indicating the need of redrawing a window are handled internally by Xt.

Lower-level libraries, such as [[XCB]], provide asynchronous access to the protocol, allowing better latency hiding.