home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-07-29 | 26.9 KB | 1,027 lines |
- .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 (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
- .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 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
- .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 IPC 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
-