[ Previous | Next | Contents | Glossary | Home | Search ]
Motif 2.1 Programmer's Guide

The X Window System

Motif is based on the X Window System, often abbreviated as X. The X Window System is fundamentally a protocol by which an application can generate output on a computer that has a bitmapped display and can receive input from devices associated with the display.

X is based on a client-server computing model. The application program is the client, communicating through the X protocol with a server that handles the direct output to and input from the display. This model has several important features:

  1. The client and server may be running on the same machine or on different machines, communicating over a network.

  2. Only the server need concern itself with the display hardware. The X protocol is hardware independent, so a client can run without alteration using any kind of display that supports the protocol.

  3. A server may handle multiple clients on the same display at the same time. These clients may communicate with each other, using the server to transfer information.

  4. A client may communicate with multiple servers.

    A display is an abstraction that represents the input and output devices controlled by a single server. Usually a display consists of a keyboard, a pointing device, and one or more screens. A screen is an abstraction that represents a single bitmapped output device.

    Each client creates one or more windows on one or more screens of a given display. A window is a rectangular area of the screen on which the client displays output. Windows are arranged in hierarchies of children and parents. The server maintains a tree of windows for each screen. The top-level window is the root window of the screen. Each client typically creates at least one window as a child of the root window, and any other client windows are descendants of these top-level client windows. Windows may overlap, and the server maintains a stacking order for all windows on a screen. A child window may extend beyond the boundaries of its parent, but output is clipped or suppressed outside the parent's borders.

    A client asks the server to create and destroy windows, but the windows themselves are resources controlled by the server. The server maintains other resources, including the following:

    1. A pixmap is a rectangular off-screen area into which an application can draw output. Both windows and pixmaps are drawables or entities on which a client can display output. The units of height and width in windows and pixmaps are pixels. Each pixel has a given depth, represented as a number of bits or planes. Thus, each pixel has an integral value whose range depends on the depth of the drawable. A one-bit-deep pixmap is called a bitmap. Each pixel in a bitmap has two possible values: 0 and 1.

    2. A colormap is an association between pixel values and colors. Each color is represented by a triple of red, green, and blue values that result in a particular color on a particular screen. Each window has an associated colormap that determines what color is used to display each pixel.

    3. A font is a collection of glyphs usually used to display text.

    4. A cursor is an object containing information needed for a graphical representation of the position of the pointer. It consists of a source bitmap, a shape bitmap, a hotspot or location representing the actual pointer position, and two colors.

    5. A graphics context or GC is a collection of attributes that determine how any given graphics operation affects a drawable. Each graphics operation on a drawable is executed using a given GC specified by the client. Some attributes of a GC are the foreground pixel, background pixel, line width, and clipping region.

    6. A property is a named data structure associated with a window. Clients often use properties to communicate with each other.

      Each client opens a connection to one or more servers. Clients and servers interact by means of requests, replies, errors, and events. A client sends a request to the server asking it to take some action, such as creating a window or drawing a line into a pixmap. Some requests, such as requests for information, cause the server to generate replies to the client. A request that results in an error condition may cause the server to generate an error report to the client. The server executes requests from each client in the order in which it receives the requests from that client, although the server may execute requests from other clients at any time.

      The server notifies clients of changes of state by means of events. An event may be a side effect of a client request, or it may have a completely asynchronous cause, such as the user's pressing a key or moving the pointer. In addition, a client may send an event, through the server, to another client.

      Each client asks the server to send that client events of particular types that occur with respect to particular windows. The server generally reports an event with respect to some window. For example, the keyboard is conceptually attached to a window, known as the focus window. When the user presses a key, the server usually reports an event with respect to the focus window. If a client has asked the server to send it events of type KeyPress occurring with respect to some window, the server sends that client an event whenever the user presses a key while that window has the focus.

      From the point of view of a client reading events from the server, events that result from that client's own requests arrive in the order in which it makes the requests. However, those events may be interspersed with events that result from other causes, such as user input or another client's actions. Furthermore, the client may buffer requests and the server may buffer events before actually transmitting them, so an event may arrive long after the client makes the request that generates the event.

      The point is that for the most part event processing in X is inherently asynchronous. Most client applications continually loop, reading an event, processing the event (possibly making requests during the processing), and then reading another event. The client cannot assume, for example, that a given input event was generated after a given client request just because the client read the event after it made the request. Many events have timestamps that indicate when the server actually generated the events. A client that depends on the temporal ordering of events must often examine these timestamps.

    7. [ Previous | Next | Contents | Glossary | Home | Search ]