1029 lines
27 KiB
Plaintext
1029 lines
27 KiB
Plaintext
|
.\" $Xorg: glossary,v 1.3 2000/08/17 19:42:25 cpqbld Exp $
|
||
|
|
.ps 11
|
||
|
|
.nr PS 11
|
||
|
|
\&
|
||
|
|
.sp 1
|
||
|
|
.XS
|
||
|
|
Glossary
|
||
|
|
.XE
|
||
|
|
.ce 1
|
||
|
|
\s+1\fBGlossary\fP\s-1
|
||
|
|
.sp 2
|
||
|
|
.na
|
||
|
|
.LP
|
||
|
|
.KS
|
||
|
|
\fBAccess control list\fP
|
||
|
|
.IN "Access control list" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
X maintains a list of hosts from which client programs can be run.
|
||
|
|
By default,
|
||
|
|
only programs on the local host and hosts specified in an initial list read
|
||
|
|
by the server can use the display.
|
||
|
|
Clients on the local host can change this access control list.
|
||
|
|
Some server implementations can also implement other authorization mechanisms
|
||
|
|
in addition to or in place of this mechanism.
|
||
|
|
The action of this mechanism can be conditional based on the authorization
|
||
|
|
protocol name and data received by the server at connection setup.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBActive grab\fP
|
||
|
|
.IN "Active grab" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A grab is active when the pointer or keyboard is actually owned by
|
||
|
|
the single grabbing client.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBAncestors\fP
|
||
|
|
.IN "Ancestors" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
If W is an inferior of A, then A is an ancestor of W.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBAtom\fP
|
||
|
|
.IN "Atom" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An atom is a unique ID corresponding to a string name.
|
||
|
|
Atoms are used to identify properties, types, and selections.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBackground\fP
|
||
|
|
.IN "Background" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An
|
||
|
|
.PN InputOutput
|
||
|
|
window can have a background, which is defined as a pixmap.
|
||
|
|
When regions of the window have their contents lost or invalidated,
|
||
|
|
the server will automatically tile those regions with the background.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBacking store\fP
|
||
|
|
.IN "Backing store" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
When a server maintains the contents of a window,
|
||
|
|
the pixels saved off screen are known as a backing store.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBit gravity\fP
|
||
|
|
.IN "Bit" "gravity" "@DEF@"
|
||
|
|
.IP
|
||
|
|
When a window is resized,
|
||
|
|
the contents of the window are not necessarily discarded.
|
||
|
|
It is possible to request that the server relocate the previous contents
|
||
|
|
to some region of the window (though no guarantees are made).
|
||
|
|
This attraction of window contents for some location of
|
||
|
|
a window is known as bit gravity.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBit plane\fP
|
||
|
|
.IN "Bit" "plane" "@DEF@"
|
||
|
|
.IP
|
||
|
|
When a pixmap or window is thought of as a stack of bitmaps,
|
||
|
|
each bitmap is called a bit plane or plane.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBitmap\fP
|
||
|
|
.IN "Bitmap" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A bitmap is a pixmap of depth one.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBBorder\fP
|
||
|
|
.IN "Border" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An
|
||
|
|
.PN InputOutput
|
||
|
|
window can have a border of equal thickness on all four sides of the window.
|
||
|
|
A pixmap defines the contents of the border,
|
||
|
|
and the server automatically maintains the contents of the border.
|
||
|
|
Exposure events are never generated for border regions.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBButton grabbing\fP
|
||
|
|
.IN "Button" "grabbing" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Buttons on the pointer may be passively grabbed by a client.
|
||
|
|
When the button is pressed,
|
||
|
|
the pointer is then actively grabbed by the client.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBByte order\fP
|
||
|
|
.IN "Byte order" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
For image (pixmap/bitmap) data,
|
||
|
|
the server defines the byte order,
|
||
|
|
and clients with different native byte ordering must swap bytes as necessary.
|
||
|
|
For all other parts of the protocol,
|
||
|
|
the client defines the byte order,
|
||
|
|
and the server swaps bytes as necessary.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBChildren\fP
|
||
|
|
.IN "Children" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The children of a window are its first-level subwindows.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBClient\fP
|
||
|
|
.IN "Client" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An application program connects to the window system server by some
|
||
|
|
interprocess communication 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 communication 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.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBClipping region\fP
|
||
|
|
.IN "Clipping region" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
In a graphics context,
|
||
|
|
a bitmap or list of rectangles can be specified
|
||
|
|
to restrict output to a particular region of the window.
|
||
|
|
The image defined by the bitmap or rectangles is called a clipping region.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBColormap\fP
|
||
|
|
.IN "Colormap" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A colormap consists of a set of entries defining color values.
|
||
|
|
The colormap associated with a window is used to display the contents of
|
||
|
|
the window; each pixel value indexes the colormap to produce RGB values
|
||
|
|
that drive the guns of a monitor.
|
||
|
|
Depending on hardware limitations,
|
||
|
|
one or more colormaps may be installed at one time,
|
||
|
|
so that windows associated with those maps display with correct colors.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBConnection\fP
|
||
|
|
.IN "Connection" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The interprocess communication path between the server and client
|
||
|
|
program is known as a connection.
|
||
|
|
A client program typically (but not necessarily) has one
|
||
|
|
connection to the server over which requests and events are sent.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBContainment\fP
|
||
|
|
.IN "Containment" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A window ``contains'' the pointer if the window is viewable and the
|
||
|
|
hotspot of the cursor is within a visible region of the window or a
|
||
|
|
visible region of one of its inferiors.
|
||
|
|
The border of the window is included as part of the window for containment.
|
||
|
|
The pointer is ``in'' a window if the window contains the pointer
|
||
|
|
but no inferior contains the pointer.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBCoordinate system\fP
|
||
|
|
.IN "Coordinate system" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The coordinate system has the X axis horizontal and the Y axis vertical,
|
||
|
|
with the origin [0, 0] at the upper left.
|
||
|
|
Coordinates are integral,
|
||
|
|
in terms of pixels,
|
||
|
|
and coincide with pixel centers.
|
||
|
|
Each window and pixmap has its own coordinate system.
|
||
|
|
For a window,
|
||
|
|
the origin is inside the border at the inside upper left.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBCursor\fP
|
||
|
|
.IN "Cursor" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A cursor is the visible shape of the pointer on a screen.
|
||
|
|
It consists of a hot spot, a source bitmap, a shape bitmap,
|
||
|
|
and a pair of colors.
|
||
|
|
The cursor defined for a window controls the visible appearance
|
||
|
|
when the pointer is in that window.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBDepth\fP
|
||
|
|
.IN "Depth" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The depth of a window or pixmap is the number of bits per pixel that it has.
|
||
|
|
The depth of a graphics context is the depth of the drawables it can be
|
||
|
|
used in conjunction with for graphics output.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBDevice\fP
|
||
|
|
.IN "Device" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Keyboards, mice, tablets, track-balls, button boxes, and so on are all
|
||
|
|
collectively known as input devices.
|
||
|
|
The core protocol only deals with two devices,
|
||
|
|
``the keyboard'' and ``the pointer.''
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBDirectColor\fP
|
||
|
|
.IN "DirectColor" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN DirectColor
|
||
|
|
is a class of colormap in which a pixel value is decomposed into three
|
||
|
|
separate subfields for indexing.
|
||
|
|
The first subfield indexes an array to produce red intensity values.
|
||
|
|
The second subfield indexes a second array to produce blue intensity values.
|
||
|
|
The third subfield indexes a third array to produce green intensity values.
|
||
|
|
The RGB values can be changed dynamically.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBDisplay\fP
|
||
|
|
.IN "Display" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A server, together with its screens and input devices, is called a display.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBDrawable\fP
|
||
|
|
.IN "Drawable" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Both windows and pixmaps can be used as sources and destinations in
|
||
|
|
graphics operations.
|
||
|
|
These windows and pixmaps are collectively known as drawables.
|
||
|
|
However, an
|
||
|
|
.PN InputOnly
|
||
|
|
window cannot be used as a source or destination in a graphics operation.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBEvent\fP
|
||
|
|
.IN "Event" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Clients are informed of information asynchronously by means of events.
|
||
|
|
These events can be generated either asynchronously from devices
|
||
|
|
or as side effects of client requests.
|
||
|
|
Events are grouped into types.
|
||
|
|
The server never sends events to a client unless the
|
||
|
|
client has specificially asked to be informed of that type of event.
|
||
|
|
However, other clients can force events to be sent to other clients.
|
||
|
|
Events are typically reported relative to a window.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBEvent mask\fP
|
||
|
|
.IN "Event" "mask" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Events are requested relative to a window.
|
||
|
|
The set of event types that a client requests relative to a window
|
||
|
|
is described by using an event mask.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBEvent synchronization\fP
|
||
|
|
.IN "Event" "synchronization" "@DEF@"
|
||
|
|
.IP
|
||
|
|
There are certain race conditions possible when demultiplexing device
|
||
|
|
events to clients (in particular deciding where pointer and keyboard
|
||
|
|
events should be sent when in the middle of window management
|
||
|
|
operations).
|
||
|
|
The event synchronization mechanism allows synchronous processing
|
||
|
|
of device events.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBEvent propagation\fP
|
||
|
|
.IN "Event" "propagation" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Device-related events propagate from the source window to ancestor
|
||
|
|
windows until some client has expressed interest in handling that type
|
||
|
|
of event or until the event is discarded explicitly.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBEvent source\fP
|
||
|
|
.IN "Event" "source" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The window the pointer is in is the source of a device-related
|
||
|
|
event.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBExposure event\fP
|
||
|
|
.IN "Event" "Exposure" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Servers do not guarantee to preserve the contents of windows when
|
||
|
|
windows are obscured or reconfigured.
|
||
|
|
Exposure events are sent to clients to inform them when contents
|
||
|
|
of regions of windows have been lost.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBExtension\fP
|
||
|
|
.IN "Extension" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Named extensions to the core protocol can be defined to extend the
|
||
|
|
system.
|
||
|
|
Extension to output requests, resources, and event types are
|
||
|
|
all possible and are expected.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBFocus window\fP
|
||
|
|
.IN "Focus window" "" ""@DEF@"
|
||
|
|
.IP
|
||
|
|
The focus window is another term for the input focus.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBFont\fP
|
||
|
|
.IN "Font" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A font is a matrix of glyphs (typically characters).
|
||
|
|
The protocol does no translation or interpretation of character sets.
|
||
|
|
The client simply indicates values used to index the glyph array.
|
||
|
|
A font contains additional metric information to determine interglyph
|
||
|
|
and interline spacing.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGC\fP, \fBGContext\fP
|
||
|
|
.IN "GC" "" "@DEF@"
|
||
|
|
.IN "GContext" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
GC and gcontext are abbreviations for graphics context.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGlyph\fP
|
||
|
|
.IN "Glyph" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A glyph is an image, typically of a character, in a font.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGrab\fP
|
||
|
|
.IN "Grab" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
|
||
|
|
server can be grabbed for exclusive use by a client.
|
||
|
|
In general,
|
||
|
|
these facilities are not intended to be used by normal applications
|
||
|
|
but are intended for various input and window managers to implement
|
||
|
|
various styles of user interfaces.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGraphics context\fP
|
||
|
|
.IN "Graphics context" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Various information for graphics output is stored in a graphics context
|
||
|
|
such as foreground pixel, background pixel, line width, clipping region,
|
||
|
|
and so on.
|
||
|
|
A graphics context can only be used with drawables that have the same root
|
||
|
|
and the same depth as the graphics context.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGravity\fP
|
||
|
|
.IN "Gravity" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
See \fBbit gravity\fP and \fBwindow gravity\fP.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBGrayScale\fP
|
||
|
|
.IN "GrayScale" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN GrayScale
|
||
|
|
can be viewed as a degenerate case of
|
||
|
|
.PN PseudoColor ,
|
||
|
|
in which the red, green, and blue values in any given colormap entry are equal,
|
||
|
|
thus producing shades of gray.
|
||
|
|
The gray values can be changed dynamically.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBHotspot\fP
|
||
|
|
.IN "Hotspot" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A cursor has an associated hotspot that defines the point in the
|
||
|
|
cursor corresponding to the coordinates reported for the pointer.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBIdentifier\fP
|
||
|
|
.IN "Identifier" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An identifier is a unique value associated with a resource that clients use
|
||
|
|
to name that resource.
|
||
|
|
The identifier can be used over any connection.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBInferiors\fP
|
||
|
|
.IN "Inferiors" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The inferiors of a window are all of the subwindows nested below it:
|
||
|
|
the children, the children's children, and so on.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBInput focus\fP
|
||
|
|
.IN "Input focus" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The input focus is normally a window defining the scope for
|
||
|
|
processing of keyboard input.
|
||
|
|
If a generated keyboard event would normally be reported to this window
|
||
|
|
or one of its inferiors,
|
||
|
|
the event is reported normally.
|
||
|
|
Otherwise, the event is reported with respect to
|
||
|
|
the focus window.
|
||
|
|
The input focus also can be set such that all
|
||
|
|
keyboard events are discarded and such that the focus
|
||
|
|
window is dynamically taken to be the root window of whatever screen
|
||
|
|
the pointer is on at each keyboard event.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBInput manager\fP
|
||
|
|
.IN "Input manager" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Control over keyboard input is typically provided by an input manager client.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBInputOnly window\fP
|
||
|
|
.IN "Window" "InputOnly" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An
|
||
|
|
.PN InputOnly
|
||
|
|
window is a window that cannot be used for graphics requests.
|
||
|
|
.PN InputOnly
|
||
|
|
windows are invisible and can be used to control such things
|
||
|
|
as cursors, input event generation, and grabbing.
|
||
|
|
.PN InputOnly
|
||
|
|
windows cannot have
|
||
|
|
.PN InputOutput
|
||
|
|
windows as inferiors.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBInputOutput window\fP
|
||
|
|
.IN "Window" "InputOutput" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An
|
||
|
|
.PN InputOutput
|
||
|
|
window is the normal kind of opaque window, used for both input and output.
|
||
|
|
.PN InputOutput
|
||
|
|
windows can have both
|
||
|
|
.PN InputOutput
|
||
|
|
and
|
||
|
|
.PN InputOnly
|
||
|
|
windows as inferiors.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBKey grabbing\fP
|
||
|
|
.IN "Key" "grabbing" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Keys on the keyboard can be passively grabbed by a client.
|
||
|
|
When the key is pressed,
|
||
|
|
the keyboard is then actively grabbed by the client.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBKeyboard grabbing\fP
|
||
|
|
.IN "Keyboard" "grabbing" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A client can actively grab control of the keyboard, and key events
|
||
|
|
will be sent to that client rather than the client the events would
|
||
|
|
normally have been sent to.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBKeysym\fP
|
||
|
|
.IN "Keysym" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An encoding of a symbol on a keycap on a keyboard.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBMapped\fP
|
||
|
|
.IN "Mapped window" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A window is said to be mapped if a map call has been performed on it.
|
||
|
|
Unmapped windows and their inferiors are never viewable or visible.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBModifier keys\fP
|
||
|
|
.IN "Modifier keys" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
|
||
|
|
ShiftLock, and similar keys are called modifier keys.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBMonochrome\fP
|
||
|
|
.IN "Monochrome" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Monochrome is a special case of
|
||
|
|
.PN StaticGray
|
||
|
|
in which there are only two colormap entries.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBObscure\fP
|
||
|
|
.IN "Obscure" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A window is obscured if some other window obscures it.
|
||
|
|
Window A obscures window B if both are viewable
|
||
|
|
.PN InputOutput
|
||
|
|
windows, A is higher in the global stacking order,
|
||
|
|
and the rectangle defined by the outside edges of A intersects
|
||
|
|
the rectangle defined by the outside edges of B.
|
||
|
|
Note the distinction between obscure and occludes.
|
||
|
|
Also note that window borders are included in the calculation
|
||
|
|
and that a window can be obscured and yet still have visible regions.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBOcclude\fP
|
||
|
|
.IN "Occlude" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A window is occluded if some other window occludes it.
|
||
|
|
Window A occludes window B if both are mapped, A is higher in the global
|
||
|
|
stacking order, and the rectangle defined by the outside edges of A
|
||
|
|
intersects the rectangle defined by the outside edges of B.
|
||
|
|
Note the distinction between occludes and obscures.
|
||
|
|
Also note that window borders are included in the calculation.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPadding\fP
|
||
|
|
.IN "Padding" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Some padding bytes are inserted in the data stream to maintain
|
||
|
|
alignment of the protocol requests on natural boundaries.
|
||
|
|
This increases ease of portability to some machine architectures.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBParent window\fP
|
||
|
|
.IN "Window" "parent" "@DEF@"
|
||
|
|
.IP
|
||
|
|
If C is a child of P, then P is the parent of C.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPassive grab\fP
|
||
|
|
.IN "Passive grab" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Grabbing a key or button is a passive grab.
|
||
|
|
The grab activates when the key or button is actually pressed.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPixel value\fP
|
||
|
|
.IN "Pixel value" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A pixel is an N-bit value, where N is the number of bit planes used
|
||
|
|
in a particular window or pixmap (that is,
|
||
|
|
N is the depth of the window or pixmap).
|
||
|
|
For a window,
|
||
|
|
a pixel value indexes a colormap to derive an actual color to be displayed.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPixmap\fP
|
||
|
|
.IN "Pixmap" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A pixmap is a three-dimensional array of bits.
|
||
|
|
A pixmap is normally thought of as a two-dimensional array of pixels,
|
||
|
|
where each pixel can be a value from 0 to (2^N)-1
|
||
|
|
and where N is the depth (z axis) of the pixmap.
|
||
|
|
A pixmap can also be thought of as a stack of N bitmaps.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPlane\fP
|
||
|
|
.IN "Plane" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
When a pixmap or window is thought of as a stack of bitmaps,
|
||
|
|
each bitmap is called a plane or bit plane.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPlane mask\fP
|
||
|
|
.IN "Plane" "mask" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Graphics operations can be restricted to only affect a subset of bit
|
||
|
|
planes of a destination.
|
||
|
|
A plane mask is a bit mask describing which planes are to be modified.
|
||
|
|
The plane mask is stored in a graphics context.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPointer\fP
|
||
|
|
.IN "Pointer" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The pointer is the pointing device attached to the cursor
|
||
|
|
and tracked on the screens.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPointer grabbing\fP
|
||
|
|
.IN "Pointer" "grabbing" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A client can actively grab control of the pointer.
|
||
|
|
Then button and motion events will be sent to that client
|
||
|
|
rather than the client the events would normally have been sent to.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPointing device\fP
|
||
|
|
.IN "Pointing device" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A pointing device is typically a mouse, tablet, or some other
|
||
|
|
device with effective dimensional motion.
|
||
|
|
There is only one visible cursor defined by the core protocol,
|
||
|
|
and it tracks whatever pointing device is attached as the pointer.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBProperty\fP
|
||
|
|
.IN "Property" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Windows may have associated properties,
|
||
|
|
which consist 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 use properties to share information such as resize
|
||
|
|
hints, program names, and icon formats with a window manager.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBProperty list\fP
|
||
|
|
.IN "Property list" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The property list of a window is the list of properties that have
|
||
|
|
been defined for the window.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBPseudoColor\fP
|
||
|
|
.IN "PseudoColor" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN PseudoColor
|
||
|
|
is a class of colormap in which a pixel value indexes the colormap to
|
||
|
|
produce independent red, green, and blue values;
|
||
|
|
that is, the colormap is viewed as an array of triples (RGB values).
|
||
|
|
The RGB values can be changed dynamically.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBRedirecting control\fP
|
||
|
|
.IN "Redirecting control" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Window managers (or client programs) may want to enforce window layout
|
||
|
|
policy in various ways.
|
||
|
|
When a client attempts to change the size or position of a window,
|
||
|
|
the operation may be redirected to a specified client
|
||
|
|
rather than the operation actually being performed.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBReply\fP
|
||
|
|
.IN "Reply" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Information requested by a client program 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,
|
||
|
|
although some requests generate multiple replies.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBRequest\fP
|
||
|
|
.IN "Request" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A command to the server is called a request.
|
||
|
|
It is a single block of data sent over a connection.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBResource\fP
|
||
|
|
.IN "Resource" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
|
||
|
|
known as resources.
|
||
|
|
They all have unique identifiers associated with them for naming purposes.
|
||
|
|
The lifetime of a resource usually is bounded by the lifetime of the connection
|
||
|
|
over which the resource was created.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBRGB values\fP
|
||
|
|
.IN "RGB values" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Red, green, and blue (RGB) intensity values are used to define color.
|
||
|
|
These values are always represented as 16-bit unsigned numbers,
|
||
|
|
with 0 being the minimum intensity and 65535 being the maximum intensity.
|
||
|
|
The server scales the values to match the display hardware.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBRoot\fP
|
||
|
|
.IN "Root" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The root of a pixmap, colormap, or graphics context is the same as the root of
|
||
|
|
whatever drawable was used when the pixmap, colormap, or graphics context was
|
||
|
|
created.
|
||
|
|
The root of a window is the root window under which the window was created.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBRoot window\fP
|
||
|
|
.IN "Window" "root" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Each screen has a root window covering it.
|
||
|
|
It cannot be reconfigured or unmapped,
|
||
|
|
but it otherwise acts as a full-fledged window.
|
||
|
|
A root window has no parent.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBSave set\fP
|
||
|
|
.IN "Save set" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The save set of a client is a list of other clients' windows that,
|
||
|
|
if they are inferiors of one of the client's windows at connection close,
|
||
|
|
should not be destroyed and that should be remapped if currently unmapped.
|
||
|
|
Save sets are typically used by window managers to avoid
|
||
|
|
lost windows if the manager terminates abnormally.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBScanline\fP
|
||
|
|
.IN "Scanline" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A scanline is a list of pixel or bit values viewed as a horizontal
|
||
|
|
row (all values having the same y coordinate) of an image, with the
|
||
|
|
values ordered by increasing x coordinate.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBScanline order\fP
|
||
|
|
.IN "Scanline order" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
An image represented in scanline order contains scanlines ordered by
|
||
|
|
increasing y coordinate.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBScreen\fP
|
||
|
|
.IN "Screen" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A server can 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.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBSelection\fP
|
||
|
|
.IN "Selection" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A selection can be thought of as an indirect property with dynamic
|
||
|
|
type; that is, rather than having the property stored in the server,
|
||
|
|
it is maintained by some client (the ``owner'').
|
||
|
|
A selection is global in nature and is thought of as belonging to the user
|
||
|
|
(although maintained by clients), rather than as 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 XY format or Z format.
|
||
|
|
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 on) of a paragraph selection rather than the
|
||
|
|
text of the paragraph.
|
||
|
|
The target type can also be used for other purposes.
|
||
|
|
The protocol does not constrain the semantics.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBServer\fP
|
||
|
|
.IN "Server" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The server provides the basic windowing mechanism.
|
||
|
|
It handles connections from clients,
|
||
|
|
multiplexes graphics requests onto the screens,
|
||
|
|
and demultiplexes input back to the appropriate clients.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBServer grabbing\fP
|
||
|
|
.IN "Server" "grabbing" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The server can be grabbed by a single client for exclusive use.
|
||
|
|
This prevents processing of any requests from other client connections until
|
||
|
|
the grab is completed.
|
||
|
|
This is typically only a transient state for
|
||
|
|
such things as rubber-banding, pop-up menus, or to execute requests
|
||
|
|
indivisibly.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBSibling\fP
|
||
|
|
.IN "Sibling" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Children of the same parent window are known as sibling windows.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBStacking order\fP
|
||
|
|
.IN "Stacking order" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Sibling windows may stack on top of each other.
|
||
|
|
Windows above other windows both obscure and occlude those lower windows.
|
||
|
|
This is similar to paper on a desk.
|
||
|
|
The relationship between sibling windows is known as the stacking order.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBStaticColor\fP
|
||
|
|
.IN "StaticColor" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN StaticColor
|
||
|
|
can be viewed as a degenerate case of
|
||
|
|
.PN PseudoColor
|
||
|
|
in which the RGB values are predefined and read-only.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBStaticGray\fP
|
||
|
|
.IN "StaticGray" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN StaticGray
|
||
|
|
can be viewed as a degenerate case of
|
||
|
|
.PN GrayScale
|
||
|
|
in which the gray values are predefined and read-only.
|
||
|
|
The values are typically linear or near-linear increasing ramps.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBStipple\fP
|
||
|
|
.IN "Stipple" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A stipple pattern is a bitmap that is used to tile a region that will serve
|
||
|
|
as an additional clip mask for a fill operation with the foreground
|
||
|
|
color.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBString Equivalence\fP
|
||
|
|
.IN "String Equivalence" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Two ISO Latin-1 STRING8 values are considered equal if they are the same
|
||
|
|
length and if corresponding bytes are either equal or are equivalent as
|
||
|
|
follows: decimal values 65 to 90 inclusive (characters ``A'' to ``Z'') are
|
||
|
|
pairwise equivalent to decimal values 97 to 122 inclusive
|
||
|
|
(characters ``a'' to ``z''), decimal values 192 to 214 inclusive
|
||
|
|
(characters ``A grave'' to ``O diaeresis'') are pairwise equivalent to decimal
|
||
|
|
values 224 to 246 inclusive (characters ``a grave'' to ``o diaeresis''),
|
||
|
|
and decimal values 216 to 222 inclusive (characters ``O oblique'' to ``THORN'')
|
||
|
|
are pairwise equivalent to decimal values 246 to 254 inclusive
|
||
|
|
(characters ``o oblique'' to ``thorn'').
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBTile\fP
|
||
|
|
.IN "Tile" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A pixmap can be replicated in two dimensions to tile a region.
|
||
|
|
The pixmap itself is also known as a tile.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBTimestamp\fP
|
||
|
|
.IN "Timestamp" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A timestamp is a time value, expressed in milliseconds.
|
||
|
|
It typically is the time 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 (named
|
||
|
|
.PN CurrentTime )
|
||
|
|
is never generated by the server.
|
||
|
|
This value is reserved for use in requests to represent the current
|
||
|
|
server time.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBTrueColor\fP
|
||
|
|
.IN "TrueColor" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
.PN TrueColor
|
||
|
|
can be viewed as a degenerate case of
|
||
|
|
.PN DirectColor
|
||
|
|
in which the subfields in the pixel value directly encode
|
||
|
|
the corresponding RGB values; that is, the colormap has predefined
|
||
|
|
read-only RGB values.
|
||
|
|
The values are typically linear or near-linear increasing ramps.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBType\fP
|
||
|
|
.IN "Type" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A type is an arbitrary atom used to identify the interpretation of
|
||
|
|
property data.
|
||
|
|
Types are completely uninterpreted by the server
|
||
|
|
and are solely for the benefit of clients.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBViewable\fP
|
||
|
|
.IN "Viewable" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
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.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBVisible\fP
|
||
|
|
.IN "Visible" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
A region of a window is visible if someone looking at the screen can
|
||
|
|
actually see it;
|
||
|
|
that is, the window is viewable and the region is not occluded by any
|
||
|
|
other window.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBWindow gravity\fP
|
||
|
|
.IN "Window" "gravity" "@DEF@"
|
||
|
|
.IP
|
||
|
|
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.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBWindow manager\fP
|
||
|
|
.IN "Window" "manager" "@DEF@"
|
||
|
|
.IP
|
||
|
|
Manipulation of windows on the screen and much of the user interface
|
||
|
|
(policy) is typically provided by a window manager client.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBXYFormat\fP
|
||
|
|
.IN "XYFormat" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The data for a pixmap is said to be in XY format if it is organized as
|
||
|
|
a set of bitmaps representing individual bit planes, with the planes
|
||
|
|
appearing from most-significant to least-significant in bit order.
|
||
|
|
.KE
|
||
|
|
.KS
|
||
|
|
.LP
|
||
|
|
\fBZFormat\fP
|
||
|
|
.IN "ZFormat" "" "@DEF@"
|
||
|
|
.IP
|
||
|
|
The data for a pixmap is said to be in Z format if it is organized as
|
||
|
|
a set of pixel values in scanline order.
|
||
|
|
.KE
|
||
|
|
.LP
|
||
|
|
.bp
|