diff options
Diffstat (limited to 'specs/XProtocol/glossary')
| -rw-r--r-- | specs/XProtocol/glossary | 1028 |
1 files changed, 1028 insertions, 0 deletions
diff --git a/specs/XProtocol/glossary b/specs/XProtocol/glossary new file mode 100644 index 0000000..c097720 --- /dev/null +++ b/specs/XProtocol/glossary @@ -0,0 +1,1028 @@ +.\" $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 |