Glossary

atom:-

An ``atom'' is a unique ID corresponding to a string name. Atoms are used to identify properties, types, and selections.

backing store:-

When a server maintains the contents of a window, the off-screen saved pixels are known as a ``backing store''.

bit gravity:-

When a window is resized, the contents of the window are not necessarily discarded. It is possible to request the server (though no guarantees are made) to relocate the previous contents to some region of the window. This attraction of window contents for some location of a window is known as ``bit gravity''.

byte order:-

For image (pixmap/bitmap) data, byte order is defined by the server, and clients with different native byte ordering must swap bytes as necessary. For all other parts of the protocol, the byte order is defined by the client, and the server swaps bytes as necessary.

buffers:-

Memory used to transfer data between clients

class:-

Windows can be of class InputOnly or InputOutput.

client:-

An application program connects to the window system server by some interprocess communication (IPC) path, such as a TCP connection or a shared memory buffer. This program is referred to as a ``client'' of the window system server. More precisely, the client is the IPC path itself. A program with multiple paths open to the server is viewed as multiple clients by the protocol. Resource lifetimes are controlled by connection lifetimes, not by program lifetimes.

color map:-

A ``color map'' consists of a set of cells defining color values. The color map associated with a window is used to display the contents of the window; each pixel value indexes the color map to produce RGB values that drive the guns of a monitor. Depending on hardware limitations, one or more color maps may be installed at one time such that windows associated with those maps display with true colors.

depth:-

The ``depth'' of a window or pixmap is the number of bits per pixel it has. The depth of a graphics context is the depth of the drawables it can be used in conjunction with for graphics output.

direct color:-

A class of color map in which a pixel value is decomposed into three separate subfields for indexing. One subfield indexes an array to produce red intensity values; the second subfield indexes a second array to produce blue intensity values; and the third subfield indexes a third array to produce green intensity values. The RGB (red, green, and blue) values in the colormap entry can be changed dynamically.

drawable:-

Both windows and pixmaps may be used as sources and destinations in graphics operations. These are collectively known as ``drawables''. However, an InputOnly window cannot be used as a source or destination in a graphics operation.

extension:-

Named ``extensions'' to the core protocol can be defined to extend the system. Extension to output requests, resources, and event types are all possible.

glyph:-

A glyph is a char/pattern in a font.

grab:-

If a client grabs a pointer, button + motion events are sent to that client.

graphics context:-

Various information for graphics output such as foreground pixel, background pixel, line width, clipping region, etc is stored in a ``graphics context''. A graphics context can only be used with drawables that have the same root and the same depth as the graphics context.

gravity:-

The contents of windows, or subwindows themselves, have a ``gravity''. This determines how they will be moved when a window is resized. See ``bit gravity'' and ``window gravity''.

gray scale:-

Gray scale can be viewed as a degenerate case of pseudo color, in which case the red, green, and blue values in any given color map entry are equal, thus producing shades of gray. The gray values can be changed dynamically.

identifier:-

Each resource has an ``identifier'', a unique value associated with it that clients use to name the resource. An identifier can be used over any connection to name the resource.

Image:-

Images can be handled via XImage structures which hide the diversity of image types from the routines.

InputOnly window:-

A window that cannot be used for graphics requests. InputOnly windows are ``invisible'' and can be used to control such things as cursors, input event generation, and grabbing. InputOnly windows cannot have InputOutput windows as inferiors.

InputOutput window:-

The ``normal'' kind of window that is used for both input and output. It usually has a background. InputOutput windows can have both InputOutput and InputOnly windows as inferiors.

keysym:-

An encoding of a symbol on a keycap on a keyboard.

modifier keys:-

Shift, Control, Meta, Super, Hyper, ALT, Compose, Apple, CapsLock, ShiftLock, and similar keys are called ``modifier'' keys.

monochrome:-

A special case of static gray, in which there are only two color map entries.

obscures:-

Window A ``obscures'' window B if both are viewable InputOutput windows, if A is higher in the global stacking order, and if the rectangle defined by the outside edges of A intersects the rectangle defined by the outside edges of B. Note the (fine) distinction with ``occludes''. Also note that window borders are included in the calculation.

occludes:-

Window A ``occludes'' window B if both are mapped, if A is higher in the global stacking order, and if the rectangle defined by the outside edges of A intersects the rectangle defined by the outside edges of B. Note the (fine) distinction with "obscures". Also note that window borders are included in the calculation. Note that InputOnly windows never obscure other windows but can occludes other windows.

pixel value:-

A ``pixel'' is an N-bit value (at a single point), where N is the number of bit planes (that is, the depth) used in a particular window or pixmap. A pixel in a window indexes a color map to derive an actual color to be displayed.

property:-

Windows may have associated ``properties'', consisting of a name, a type, a data format, and some data. The protocol places no interpretation on properties. They are intended as a general-purpose naming mechanism for clients. For example, clients might share information such as resize hints, program names, and icon formats with a window manager via properties.

property list:-

The ``property list'' of a window is the list of properties that have been defined for the window.

pseudo color:-

A class of color map in which a pixel value indexes the color map entry to produce independent red, green, and blue values. That is, the color map is viewed as an array of triples (RGB values). The RGB values can be changed dynamically.

Quarks:-

The resource manager that deals with Xdefaults has many strings and string comparisons to deal with. By representing each string as an integer then operations are faster. These integers are called Quarks.

Region:-

These are sets of points (not necessarily rectangles) on which arithmetic can be done.

reply:-

Information requested by a client program by means of the X protocol is sent back to the client with a ``reply.'' Both events and replies are multiplexed on the same connection. Most requests do not generate replies. Some requests generate multiple replies.

request:-

A command to the server is called a ``request''. It is a single block of data sent over a connection.

resource:-

Windows, pixmaps, cursors, fonts, graphics contexts, and color maps are known as ``resources''. They all have unique identifiers associated with them for naming purposes. The lifetime of a resource is bounded by the lifetime of the connection over which the resource was created.

RGB values:-

Red, green, and blue intensity values are used to define a color. These values are always represented as 16 bit unsigned numbers, with zero the minimum intensity and 65535 the maximum intensity. The X server scales these values to match the display hardware.

root:-

The ``root'' of a pixmap or a graphics context is the same as the root of whatever drawable was used when the pixmap or gcontext was created. The ``root'' of a window is the root window under which the window was created.

screen:-

A server may provide several independent ``screens'', which typically have physically independent monitors. This would be the expected configuration when there is only a single keyboard and pointer shared among the screens. A Screen structure contains the information about that screen and is linked to the Display structure.

selection:-

A ``selection'' can be thought of as an indirect property with dynamic type. That is, rather than having the property stored in the X server, it is maintained by some client (the ``owner"). It is global in nature, `belonging' to the user (but maintained by clients), rather than being private to a particular window subhierarchy or a particular set of clients. When a client asks for the contents of a selection, it specifies a selection ``target type''. This target type can be used to control the transmitted representation of the contents. For example, if the selection is ``the last thing the user clicked on'', and that is currently an image, then the target type might specify whether the contents of the image should be sent in XYFormat or ZFormat. The target type can also be used to control the class of contents transmitted, for example, asking for the ``looks'' (fonts, line spacing, indentation, and so forth) of a paragraph selection, rather than the text of the paragraph. The target type can also be used for other purposes. The semantics are not constrained by the protocol.

server:-

The ``server'', also referred to as the ``X server'', provides the basic windowing mechanism. It handles IPC connections from clients, demultiplexes graphics requests onto the screens, and multiplexes input back to the appropriate clients.

static color:-

Static color can be viewed as a degenerate case of pseudo color, in which the RGB values are predefined and read-only.

static gray:-

Static gray can be viewed as a degenerate case of gray scale, in which the gray values are predefined and read-only. The values are typically (near-)linear increasing ramps.

stipple:-

A ``stipple pattern'' is a bitmap that is used to tile a region to serve as an additional clip mask for a fill operation with the foreground color.

tile:-

A pixmap can be replicated in two dimensions to ``tile'' a region. The pixmap itself is also known as a ``tile''.

timestamp:-

A time value, expressed in milliseconds, typically since the last server reset. Timestamp values wrap around (after about 49.7 days). The server, given its current time is represented by timestamp T, always interprets timestamps from clients by treating half of the timestamp space as being earlier in time than T, and half of the timestamp space as being later in time than T. One timestamp value, represented by the constant CurrentTime is never generated by the server. This value is reserved for use in requests to represent the current server time.

true color:-

True color can be viewed as a degenerate case of direct color, in which the subfields in the pixel value directly encode the corresponding RGB values. That is, the color map has predefined read-only RGB values. The values are typically (near-)linear increasing ramps.

type:-

A type is an arbitrary atom used to identify the interpretation of property data. Types are completely uninterpreted by the server. They are solely for the benefit of clients. X predefines type atoms for many frequently used types, and clients also can define new types.

viewable:-

A window is ``viewable'' if it and all of its ancestors are mapped. This does not imply that any portion of the window is actually visible. Graphics requests can be performed on a window when it is not viewable, but output will not be retained unless the server is maintaining backing store.

visible:-

A region of a window is ``visible'' if someone looking at the screen can actually ``see'' it: the window is viewable and the region is not occluded by any other window.

visual:-

A visual type represents a way of interpreting the pixel values of a colormap.

widget:-

In the XToolkit a widget is an XWindow + associated semantics. They are created by combining other widgets or from scratch. Menus, Button Boxes, Scroll-barred windows and Text handlers can all be constructed using toolkit routines.

window gravity:-

When windows are resized, subwindows may be repositioned automatically relative to some position in the window. This attraction of a subwindow to some part of its parent is known as ``window gravity''.