1485 lines
40 KiB
Plaintext
1485 lines
40 KiB
Plaintext
|
\&
|
||
|
.sp 1
|
||
|
.ce 1
|
||
|
\s+1\fBGlossary\fP\s-1
|
||
|
.sp 2
|
||
|
.na
|
||
|
.LP
|
||
|
.XS
|
||
|
Glossary
|
||
|
.XE
|
||
|
.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.
|
||
|
This access control list can be changed by clients on the local host.
|
||
|
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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBAncestors\fP
|
||
|
.IN "Ancestors" "" "@DEF@"
|
||
|
.IP
|
||
|
If W is an inferior of A, then A is an ancestor of W.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 automatically tiles those regions with the background.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBBase font name\fP
|
||
|
.IN "Base font name" "" "@DEF@"
|
||
|
.IP
|
||
|
A font name used to select a family of fonts whose members may be encoded
|
||
|
in various charsets.
|
||
|
The
|
||
|
.PN CharSetRegistry
|
||
|
and
|
||
|
.PN CharSetEncoding
|
||
|
fields of an XLFD name identify the charset of the font.
|
||
|
A base font name may be a full XLFD name, with all fourteen '-' delimiters,
|
||
|
or an abbreviated XLFD name containing only the first 12 fields of an XLFD name,
|
||
|
up to but not including
|
||
|
.PN CharSetRegistry ,
|
||
|
with or without the thirteenth '-', or a non-XLFD name.
|
||
|
Any XLFD fields may contain wild cards.
|
||
|
.IP
|
||
|
When creating an
|
||
|
.PN XFontSet ,
|
||
|
Xlib accepts from the client a list of one or more base font names
|
||
|
which select one or more font families.
|
||
|
They are combined with charset names obtained from the encoding of the locale
|
||
|
to load the fonts required to render text.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBBitmap\fP
|
||
|
.IN "Bitmap" "" "@DEF@"
|
||
|
.IP
|
||
|
A bitmap is a pixmap of depth one.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBBorder\fP
|
||
|
.IN "Border" "" "@DEF@"
|
||
|
.IP
|
||
|
An
|
||
|
.PN InputOutput
|
||
|
window can have a border of equal thickness on all four sides of the window.
|
||
|
The contents of the border are defined by a pixmap,
|
||
|
and the server automatically maintains the contents of the border.
|
||
|
Exposure events are never generated for border regions.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBButton grabbing\fP
|
||
|
.IN "Button" "grabbing" "@DEF@"
|
||
|
.IP
|
||
|
Buttons on the pointer can be passively grabbed by a client.
|
||
|
When the button is pressed,
|
||
|
the pointer is then actively grabbed by the client.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCharacter\fP
|
||
|
.IN "Character" "" "@DEF@"
|
||
|
.IP
|
||
|
A member of a set of elements used for the organization,
|
||
|
control, or representation of text (ISO2022, as adapted by XPG3).
|
||
|
Note that in ISO2022 terms, a character is not bound to a coded value
|
||
|
until it is identified as part of a coded character set.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCharacter glyph\fP
|
||
|
.IN "Character glyph" "" "@DEF@"
|
||
|
.IP
|
||
|
The abstract graphical symbol for a character.
|
||
|
Character glyphs may or may not map one-to-one to font glyphs,
|
||
|
and may be context-dependent, varying with the adjacent characters.
|
||
|
Multiple characters may map to a single character glyph.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCharacter set\fP
|
||
|
.IN "Character set" "" "@DEF@"
|
||
|
.IP
|
||
|
A collection of characters.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCharset\fP
|
||
|
.IN "Charset" "" "@DEF@"
|
||
|
.IP
|
||
|
An encoding with a uniform, state-independent mapping from characters
|
||
|
to codepoints.
|
||
|
A coded character set.
|
||
|
.IP
|
||
|
For display in X,
|
||
|
there can be a direct mapping from a charset to one font,
|
||
|
if the width of all characters in the charset is either one or two bytes.
|
||
|
A text string encoded in an encoding such as Shift-JIS cannot be passed
|
||
|
directly to the X server, because the text imaging requests accept only
|
||
|
single-width charsets (either 8 or 16 bits).
|
||
|
Charsets which meet these restrictions can serve as ``font charsets''.
|
||
|
Font charsets strictly speaking map font indices to font glyphs,
|
||
|
not characters to character glyphs.
|
||
|
.IP
|
||
|
Note that a single font charset is sometimes used as the encoding of a locale,
|
||
|
for example, ISO8859-1.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBChildren\fP
|
||
|
.IN "Children" "" "@DEF@"
|
||
|
.IP
|
||
|
The children of a window are its first-level subwindows.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBClass\fP
|
||
|
.IN "Class" "" "@DEF@"
|
||
|
.IP
|
||
|
Windows can be of different classes or types.
|
||
|
See the entries for
|
||
|
.PN InputOnly
|
||
|
and
|
||
|
.PN InputOutput
|
||
|
windows for further information about valid window types.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBClient\fP
|
||
|
.IN "Client" "" "@DEF@"
|
||
|
.IP
|
||
|
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.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCoded character\fP
|
||
|
.IN "Coded character" "" "@DEF@"
|
||
|
.IP
|
||
|
A character bound to a codepoint.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCoded character set\fP
|
||
|
.IN "Coded character set" "" "@DEF@"
|
||
|
.IP
|
||
|
A set of unambiguous rules that establishes a character set
|
||
|
and the one-to-one relationship between each character of the set
|
||
|
and its bit representation.
|
||
|
(ISO2022, as adapted by XPG3)
|
||
|
A definition of a one-to-one mapping of a set of characters to a set of
|
||
|
codepoints.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCodepoint\fP
|
||
|
.IN "Codepoint" "" "@DEF@"
|
||
|
.IP
|
||
|
The coded representation of a single character in a coded character set.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 an RGB value
|
||
|
that drives the guns of a monitor.
|
||
|
Depending on hardware limitations,
|
||
|
one or more colormaps can be installed at one time so
|
||
|
that windows associated with those maps display with true colors.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBConnection\fP
|
||
|
.IN "Connection" "" "@DEF@"
|
||
|
.IP
|
||
|
The IPC 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCoordinate system\fP
|
||
|
.IN "Coordinate system" "" "@DEF@"
|
||
|
.IP
|
||
|
The coordinate system has X horizontal and Y vertical,
|
||
|
with the origin [0, 0] at the upper left.
|
||
|
Coordinates are integral 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 corner.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBCursor\fP
|
||
|
.IN "Cursor" "" "@DEF@"
|
||
|
.IP
|
||
|
A cursor is the visible shape of the pointer on a screen.
|
||
|
It consists of a hotspot, 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBDepth\fP
|
||
|
.IN "Depth" "" "@DEF@"
|
||
|
.IP
|
||
|
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 graphics output.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBDevice\fP
|
||
|
.IN "Device" "" "@DEF@"
|
||
|
.IP
|
||
|
Keyboards, mice, tablets, track-balls, button boxes, and so on are all
|
||
|
collectively known as input devices.
|
||
|
Pointers can have one or more buttons
|
||
|
(the most common number is three).
|
||
|
The core protocol only deals with two devices: the keyboard
|
||
|
and the pointer.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 (red, green, and blue) values in the colormap entry can be
|
||
|
changed dynamically.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBDisplay\fP
|
||
|
.IN "Display" "" "@DEF@"
|
||
|
.IP
|
||
|
A server, together with its screens and input devices, is called a display.
|
||
|
The Xlib
|
||
|
.PN Display
|
||
|
.IN "Display" "structure"
|
||
|
structure contains all information about the particular display and its screens
|
||
|
as well as the state that Xlib needs to communicate with the display over a
|
||
|
particular connection.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBEncoding\fP
|
||
|
.IN "Encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
A set of unambiguous rules that establishes a character set
|
||
|
and a relationship between the characters and their representations.
|
||
|
The character set does not have to be fixed to a finite pre-defined set of
|
||
|
characters.
|
||
|
The representations do not have to be of uniform length.
|
||
|
Examples are an ISO2022 graphic set, a state-independent
|
||
|
or state-dependent combination of graphic sets, possibly including control
|
||
|
sets, and the X Compound Text encoding.
|
||
|
.IP
|
||
|
In X, encodings are identified by a string
|
||
|
which appears as: the
|
||
|
.PN CharSetRegistry
|
||
|
and
|
||
|
.PN CharSetEncoding
|
||
|
components of an XLFD
|
||
|
name; the name of a charset of the locale for which a font could not be
|
||
|
found; or an atom which identifies the encoding of a text property or
|
||
|
which names an encoding for a text selection target type.
|
||
|
Encoding names should be composed of characters from the X Portable
|
||
|
Character Set.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBEscapement\fP
|
||
|
.IN "Escapement" "" "@DEF@"
|
||
|
.IP
|
||
|
The escapement of a string is the distance in pixels in the
|
||
|
primary draw direction from the drawing origin to the origin of the next
|
||
|
character (that is, the one following the given string) to be drawn.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBEvent\fP
|
||
|
.IN "Event" "" "@DEF@"
|
||
|
.IP
|
||
|
Clients are informed of information asynchronously by means of events.
|
||
|
These events can be either asynchronously generated from devices or
|
||
|
generated as side effects of client requests.
|
||
|
Events are grouped into types.
|
||
|
The server never sends an event to a client unless the
|
||
|
client has specifically asked to be informed of that type of event.
|
||
|
However, clients can force events to be sent to other clients.
|
||
|
Events are typically reported relative to a window.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBEvent mask\fP
|
||
|
.IN "Event" "mask" "@DEF@"
|
||
|
.IP
|
||
|
Events are requested relative to a window.
|
||
|
The set of event types a client requests relative to a window is described
|
||
|
by using an event mask.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBEvent source\fP
|
||
|
.IN "Event" "source" "@DEF@"
|
||
|
.IP
|
||
|
The deepest viewable window that the pointer is in is called
|
||
|
the source of a device-related event.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBExtension\fP
|
||
|
.IN "Extension" "" "@DEF@"
|
||
|
.IP
|
||
|
Named extensions to the core protocol can be defined to extend the system.
|
||
|
Extensions to output requests, resources, and event types are all possible
|
||
|
and expected.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBFont\fP
|
||
|
.IN "Font" "" "@DEF@"
|
||
|
.IP
|
||
|
A font is an array 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBFont glyph\fP
|
||
|
.IN "Font glyph" "" "@DEF@"
|
||
|
.IP
|
||
|
The abstract graphical symbol for an index into a font.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBFrozen events\fP
|
||
|
.IN "Frozen events" "" "@DEF@"
|
||
|
.IP
|
||
|
Clients can freeze event processing during keyboard and pointer grabs.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBGC\fP
|
||
|
.IN "GC" "" "@DEF@"
|
||
|
.IP
|
||
|
GC is an abbreviation for graphics context.
|
||
|
See \fBGraphics context\fP.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBGlyph\fP
|
||
|
.IN "Glyph" "" "@DEF@"
|
||
|
.IP
|
||
|
An identified abstract graphical symbol independent of any actual image.
|
||
|
(ISO/IEC/DIS 9541-1)
|
||
|
An abstract visual representation of a graphic character,
|
||
|
not bound to a codepoint.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBGlyph image\fP
|
||
|
.IN "Glyph image" "" "@DEF@"
|
||
|
.IP
|
||
|
An image of a glyph, as obtained from a glyph representation displayed
|
||
|
on a presentation surface.
|
||
|
(ISO/IEC/DIS 9541-1)
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBGraphics context\fP
|
||
|
.IN "Graphics context" "" "@DEF@"
|
||
|
.IP
|
||
|
Various information for graphics output is stored in a graphics
|
||
|
context (GC), 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBGravity\fP
|
||
|
.IN "Gravity" "" "@DEF@"
|
||
|
.IP
|
||
|
The contents of windows and windows themselves have a gravity,
|
||
|
which determines how the contents move when a window is resized.
|
||
|
See \fBBit gravity\fP and \fBWindow gravity\fP.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 and thus, produce shades of gray.
|
||
|
The gray values can be changed dynamically.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBHost Portable Character Encoding\fP
|
||
|
.IN "Host Portable Character Encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
The encoding of the X Portable Character Set on the host.
|
||
|
The encoding itself is not defined by this standard,
|
||
|
but the encoding must be the same in all locales supported by Xlib on the host.
|
||
|
If a string is said to be in the Host Portable Character Encoding,
|
||
|
then it only contains characters from the X Portable Character Set,
|
||
|
in the host encoding.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBHotspot\fP
|
||
|
.IN "Hotspot" "" "@DEF@"
|
||
|
.IP
|
||
|
A cursor has an associated hotspot, which defines the point in the
|
||
|
cursor corresponding to the coordinates reported for the pointer.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 to name the resource.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBInput focus\fP
|
||
|
.IN "Input" "focus" "@DEF@"
|
||
|
.IP
|
||
|
The input focus is usually a window defining the scope for processing
|
||
|
of keyboard input.
|
||
|
If a generated keyboard event usually would be reported to this window
|
||
|
or one of its inferiors,
|
||
|
the event is reported as usual.
|
||
|
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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBInput manager\fP
|
||
|
.IN "Input" "manager" "@DEF@"
|
||
|
.IP
|
||
|
Control over keyboard input is typically provided by an input manager
|
||
|
client, which usually is part of a window manager.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 are used to control such things as cursors,
|
||
|
input event generation, and grabbing.
|
||
|
.PN InputOnly
|
||
|
windows cannot have
|
||
|
.PN InputOutput
|
||
|
windows as inferiors.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBInputOutput window\fP
|
||
|
.IN "Window" "InputOutput" "@DEF@"
|
||
|
.IP
|
||
|
An
|
||
|
.PN InputOutput
|
||
|
window is the normal kind of window that is used for both input and output.
|
||
|
.PN InputOutput
|
||
|
windows can have both
|
||
|
.PN InputOutput
|
||
|
and
|
||
|
.PN InputOnly
|
||
|
windows as inferiors.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBInternationalization\fP
|
||
|
.IN "Internationalization" "" "@DEF@"
|
||
|
.IP
|
||
|
The process of making software adaptable to the requirements
|
||
|
of different native languages, local customs, and character string encodings.
|
||
|
Making a computer program adaptable to different locales
|
||
|
without program source modifications or recompilation.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBISO2022\fP
|
||
|
.IN "ISO2022" "" "@DEF@"
|
||
|
.IP
|
||
|
ISO standard for code extension techniques for 7-bit and 8-bit coded
|
||
|
character sets.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBKeysym\fP
|
||
|
.IN "Keysym" "" "@DEF@"
|
||
|
.IP
|
||
|
An encoding of a symbol on a keycap on a keyboard.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBLatin-1\fP
|
||
|
.IN "Latin-1" "" "@DEF@"
|
||
|
.IP
|
||
|
The coded character set defined by the ISO8859-1 standard.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBLatin Portable Character Encoding\fP
|
||
|
.IN "Latin Portable Character Encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
The encoding of the X Portable Character Set using the Latin-1 codepoints
|
||
|
plus ASCII control characters.
|
||
|
If a string is said to be in the Latin Portable Character Encoding,
|
||
|
then it only contains characters from the X Portable Character Set,
|
||
|
not all of Latin-1.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBLocale\fP
|
||
|
.IN "Locale" "" "@DEF@"
|
||
|
.IP
|
||
|
The international environment of a computer program defining the ``localized''
|
||
|
behavior of that program at run-time.
|
||
|
This information can be established from one or more sets of localization data.
|
||
|
ANSI C defines locale-specific processing by C system library calls.
|
||
|
See ANSI C and the X/Open Portability Guide specifications for more details.
|
||
|
In this specification, on implementations that conform to the ANSI C library,
|
||
|
the ``current locale'' is the current setting of the LC_CTYPE
|
||
|
.PN setlocale
|
||
|
category.
|
||
|
Associated with each locale is a text encoding. When text is processed
|
||
|
in the context of a locale, the text must be in the encoding of the locale.
|
||
|
The current locale affects Xlib in its:
|
||
|
.RS
|
||
|
.IP \(bu 5
|
||
|
Encoding and processing of input method text
|
||
|
.IP \(bu 5
|
||
|
Encoding of resource files and values
|
||
|
.IP \(bu 5
|
||
|
Encoding and imaging of text strings
|
||
|
.IP \(bu 5
|
||
|
Encoding and decoding for inter-client text communication
|
||
|
.RE
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBLocale name\fP
|
||
|
.IN "Locale name" "" "@DEF@"
|
||
|
.IP
|
||
|
The identifier used to select the desired locale for the host C library
|
||
|
and X library functions.
|
||
|
On ANSI C library compliant systems,
|
||
|
the locale argument to the
|
||
|
.PN setlocale
|
||
|
function.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBLocalization\fP
|
||
|
.IN "Localization" "" "@DEF@"
|
||
|
.IP
|
||
|
The process of establishing information within a computer system specific
|
||
|
to the operation of particular native languages, local customs
|
||
|
and coded character sets.
|
||
|
(XPG3)
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBMonochrome\fP
|
||
|
.IN "Monochrome" "" "@DEF@"
|
||
|
.IP
|
||
|
Monochrome is a special case of
|
||
|
.PN StaticGray
|
||
|
in which there are only two colormap entries.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBMultibyte\fP
|
||
|
.IN "Multibyte" "" "@DEF@"
|
||
|
.IP
|
||
|
A character whose codepoint is stored in more than one byte;
|
||
|
any encoding which can contain multibyte characters;
|
||
|
text in a multibyte encoding.
|
||
|
The ``char *'' null-terminated string datatype in ANSI C.
|
||
|
Note that references in this document to multibyte strings
|
||
|
imply only that the strings \fImay\fP contain multibyte characters.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBObscure\fP
|
||
|
.IN "Obscure" "" "@DEF@"
|
||
|
.IP
|
||
|
A window is obscured if some other window obscures it.
|
||
|
A window can be partially obscured and so still have visible regions.
|
||
|
Window A obscures window B if both are viewable
|
||
|
.PN 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 distinction between obscures and occludes.
|
||
|
Also note that window borders are included in the calculation.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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,
|
||
|
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 distinction between occludes and obscures.
|
||
|
Also note that window borders are included in the calculation
|
||
|
and that
|
||
|
.PN InputOnly
|
||
|
windows never obscure other windows but can occlude other windows.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBParent window\fP
|
||
|
.IN "Window" "parent" "@DEF@"
|
||
|
.IP
|
||
|
If C is a child of P, then P is the parent of C.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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, is the depth of the window or pixmap).
|
||
|
A pixel in a window indexes a colormap to derive an actual color to be
|
||
|
displayed.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPixmap\fP
|
||
|
.IN "Pixmap" "" "@DEF@"
|
||
|
.EQ
|
||
|
delim %%
|
||
|
.EN
|
||
|
.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 sup 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.
|
||
|
A pixmap can only be used on the screen that it was created in.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPointer\fP
|
||
|
.IN "Pointer" "" "@DEF@"
|
||
|
.IP
|
||
|
The pointer is the pointing device currently attached to the cursor
|
||
|
and tracked on the screens.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPointing device\fP
|
||
|
.IN "Pointing device" "" "@DEF@"
|
||
|
.IP
|
||
|
A pointing device is typically a mouse, tablet, or some other
|
||
|
device with effective dimensional motion.
|
||
|
The core protocol defines only one visible cursor,
|
||
|
which tracks whatever pointing device is attached as the pointer.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPOSIX\fP
|
||
|
.IN "POSIX" "" "@DEF@"
|
||
|
.IP
|
||
|
Portable Operating System Interface, ISO/IEC 9945-1 (IEEE Std 1003.1).
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPOSIX Portable Filename Character Set\fP
|
||
|
.IN "POSIX Portable Filename Character Set" "" "@DEF@"
|
||
|
.IP
|
||
|
The set of 65 characters which can be used in naming files on a POSIX-compliant
|
||
|
host that are correctly processed in all locales.
|
||
|
The set is:
|
||
|
.IP
|
||
|
.Ds 0
|
||
|
a..z A..Z 0..9 ._-
|
||
|
.De
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBProperty\fP
|
||
|
.IN "Property" "" "@DEF@"
|
||
|
.IP
|
||
|
Windows can have associated properties that 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBPseudoColor\fP
|
||
|
.IN "PseudoColor" "" "@DEF@"
|
||
|
.IP
|
||
|
.PN PseudoColor
|
||
|
is a class of colormap in which a pixel value indexes the colormap entry to
|
||
|
produce an independent RGB value;
|
||
|
that is, the colormap is viewed as an array of triples (RGB values).
|
||
|
The RGB values can be changed dynamically.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBRectangle\fP
|
||
|
.IN "Rectangle" "" "@DEF@"
|
||
|
.IP
|
||
|
A rectangle specified by [x,y,w,h] has an infinitely thin
|
||
|
outline path with corners at [x,y], [x+w,y], [x+w,y+h], and [x, y+h].
|
||
|
When a rectangle is filled,
|
||
|
the lower-right edges are not drawn.
|
||
|
For example,
|
||
|
if w=h=0,
|
||
|
nothing would be drawn.
|
||
|
For w=h=1,
|
||
|
a single pixel would be drawn.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBRedirecting control\fP
|
||
|
.IN "Redirecting control" "" "@DEF@"
|
||
|
.IP
|
||
|
Window managers (or client programs) may 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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBReply\fP
|
||
|
.IN "Reply" "" "@DEF@"
|
||
|
.IP
|
||
|
Information requested by a client program using 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,
|
||
|
but some requests generate multiple replies.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBRGB values\fP
|
||
|
.IN "RGB values" "" "@DEF@"
|
||
|
.IP
|
||
|
RGB values are the red, green, and blue intensity values that are used
|
||
|
to define a color.
|
||
|
These values are always represented as 16-bit, unsigned numbers, with 0
|
||
|
the minimum intensity and 65535 the maximum intensity.
|
||
|
The X server scales these values to match the display hardware.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBRoot\fP
|
||
|
.IN "Root" "" "@DEF@"
|
||
|
.IP
|
||
|
The root of a pixmap or graphics context is the same as the root
|
||
|
of whatever drawable was used when the pixmap or GC was created.
|
||
|
The root of a window is the root window under which the window was created.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBRoot window\fP
|
||
|
.IN "Window" "root" "@DEF@"
|
||
|
.IP
|
||
|
Each screen has a root window covering it.
|
||
|
The root window cannot be reconfigured or unmapped,
|
||
|
but otherwise it acts as a full-fledged window.
|
||
|
A root window has no parent.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 should terminate abnormally.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 the x coordinate.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBScanline order\fP
|
||
|
.IN "Scanline" "order" "@DEF@"
|
||
|
.IP
|
||
|
An image represented in scanline order contains scanlines ordered by
|
||
|
increasing the y coordinate.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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.
|
||
|
A
|
||
|
.PN Screen
|
||
|
.IN "Screen" "structure"
|
||
|
structure contains the information about that screen
|
||
|
and is linked to the
|
||
|
.PN Display
|
||
|
.IN "Display" "structure"
|
||
|
structure.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 X server,
|
||
|
it is maintained by some client (the owner).
|
||
|
A selection is global and is thought of as belonging to the user
|
||
|
and being 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,
|
||
|
which 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.
|
||
|
.IP
|
||
|
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 protocol does not constrain the semantics.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBServer\fP
|
||
|
.IN "Server" "" "@DEF@"
|
||
|
.IP
|
||
|
The server, which is also referred to as the X server,
|
||
|
provides the basic windowing mechanism.
|
||
|
It handles IPC connections from clients,
|
||
|
multiplexes graphics requests onto the screens,
|
||
|
and demultiplexes input back to the appropriate clients.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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 executing requests indivisibly.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBShift sequence\fP
|
||
|
.IN "Shift sequence" "" "@DEF@"
|
||
|
.IP
|
||
|
ISO2022 defines control characters and escape sequences
|
||
|
which temporarily (single shift) or permanently (locking shift) cause a
|
||
|
different character set to be in effect (``invoking'' a character set).
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBSibling\fP
|
||
|
.IN "Sibling" "" "@DEF@"
|
||
|
.IP
|
||
|
Children of the same parent window are known as sibling windows.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBStacking order\fP
|
||
|
.IN "Stacking order" "" "@DEF@"
|
||
|
.IP
|
||
|
Sibling windows, similar to sheets of paper on a desk,
|
||
|
can stack on top of each other.
|
||
|
Windows above both obscure and occlude lower windows.
|
||
|
The relationship between sibling windows is known as the stacking order.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBState-dependent encoding\fP
|
||
|
.IN "State-dependent encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
An encoding in which an invocation of a charset can apply to multiple
|
||
|
characters in sequence.
|
||
|
A state-dependent encoding begins in an ``initial state''
|
||
|
and enters other ``shift states'' when specific ``shift sequences''
|
||
|
are encountered in the byte sequence.
|
||
|
In ISO2022 terms,
|
||
|
this means use of locking shifts, not single shifts.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBState-independent encoding\fP
|
||
|
.IN "State-independent encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
Any encoding in which the invocations of the charsets are fixed,
|
||
|
or span only a single character.
|
||
|
In ISO2022 terms,
|
||
|
this means use of at most single shifts, not locking shifts.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBStatus\fP
|
||
|
.IN "Status" "" "@DEF@"
|
||
|
.IP
|
||
|
Many Xlib functions return a success status.
|
||
|
If the function does not succeed,
|
||
|
however, its arguments are not disturbed.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBStipple\fP
|
||
|
.IN "Stipple" "" "@DEF@"
|
||
|
.IP
|
||
|
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.
|
||
|
.KE
|
||
|
.KS
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBSTRING encoding\fP
|
||
|
.IN "STRING encoding" "" "@DEF@"
|
||
|
.IP
|
||
|
Latin-1, plus tab and newline.
|
||
|
.KE
|
||
|
.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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBTimestamp\fP
|
||
|
.IN "Timestamp" "" "@DEF@"
|
||
|
.IP
|
||
|
A timestamp is a time value expressed in milliseconds.
|
||
|
It is typically 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, represented by the constant
|
||
|
.PN CurrentTime ,
|
||
|
is never generated by the server.
|
||
|
This value is reserved for use in requests to represent the current server time.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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.
|
||
|
They are solely for the benefit of clients.
|
||
|
X predefines type atoms for many frequently used types,
|
||
|
and clients also can define new types.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBWhitespace\fP
|
||
|
.IN "Whitespace" "" "@DEF@"
|
||
|
.IP
|
||
|
Any spacing character.
|
||
|
On implementations that conform to the ANSI C library,
|
||
|
whitespace is any character for which
|
||
|
.PN isspace
|
||
|
returns true.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\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
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBX Portable Character Set\fP
|
||
|
.IN "X Portable Character Set" "" "@DEF@"
|
||
|
.IP
|
||
|
A basic set of 97 characters which are assumed to exist in all
|
||
|
locales supported by Xlib. This set contains the following characters:
|
||
|
.IP
|
||
|
.Ds 0
|
||
|
.EQ
|
||
|
delim DD
|
||
|
.EN
|
||
|
a..z A..Z 0..9
|
||
|
!"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~
|
||
|
<space>, <tab>, and <newline>
|
||
|
.EQ
|
||
|
delim %%
|
||
|
.EN
|
||
|
.De
|
||
|
.IP
|
||
|
This is the left/lower half (also called the G0 set)
|
||
|
of the graphic character set of ISO8859-1 plus <space>, <tab>, and <newline>.
|
||
|
It is also the set of graphic characters in 7-bit ASCII plus the same
|
||
|
three control characters.
|
||
|
The actual encoding of these characters on the host is system dependent;
|
||
|
see the Host Portable Character Encoding.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBXLFD\fP
|
||
|
.IN "XLFD" "" "@DEF@"
|
||
|
.IP
|
||
|
The X Logical Font Description Conventions that define a standard syntax
|
||
|
for structured font names.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBXY format\fP
|
||
|
.IN "XY format" "" "@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 bit order.
|
||
|
.KE
|
||
|
.LP
|
||
|
.KS
|
||
|
\fBZ format\fP
|
||
|
.IN "Z format" "" "@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
|
||
|
\fBReferences\fP
|
||
|
.LP
|
||
|
ANSI Programming Language - C: ANSI X3.159-1989, December 14, 1989.
|
||
|
.LP
|
||
|
Draft Proposed Multibyte Extension of ANSI C, Draft 1.1, November 30,
|
||
|
1989, SC22/C WG/SWG IPSJ/ITSCJ Japan.
|
||
|
.LP
|
||
|
ISO2022: Information processing - ISO 7-bit and 8-bit coded character
|
||
|
sets - Code extension techniques.
|
||
|
.LP
|
||
|
ISO8859-1: Information processing - 8-bit single-byte coded graphic
|
||
|
character sets - Part 1: Latin alphabet No. 1.
|
||
|
.LP
|
||
|
POSIX: Information Technology - Portable Operating System Interface (POSIX) -
|
||
|
Part 1: System Application Program Interface (API) [C Language],
|
||
|
ISO/IEC 9945-1.
|
||
|
.LP
|
||
|
Text of ISO/IEC/DIS 9541-1, Information Processing - Font Information
|
||
|
Interchange - Part 1: Architecture.
|
||
|
.LP
|
||
|
X/Open Portability Guide, Issue 3, December 1988 (XPG3), X/Open Company,
|
||
|
Ltd, Prentice-Hall, Inc. 1989. ISBN 0-13-685835-8.
|
||
|
(See especially Volume 3: XSI Supplementary Definitions.)
|
||
|
.bp
|