specs/glossary.xml

   1 <glossary id='glossary'>
   2 <title>Glossary</title>
   3
   4
   5 <glossentry id="glossary:Access_control_list">
   6   <glossterm>Access control list</glossterm>
   7   <indexterm zone="glossary:Access_control_list" significance="preferred"><primary>Access control list</primary></indexterm>
   8   <glossdef>
   9     <para>
  10 X maintains a list of hosts from which client programs can be run.
  11 By default,
  12 only programs on the local host and hosts specified in an initial list read
  13 by the server can use the display.
  14 Clients on the local host can change this access control list.
  15 Some server implementations can also implement other authorization mechanisms
  16 in addition to or in place of this mechanism.
  17 The action of this mechanism can be conditional based on the authorization
  18 protocol name and data received by the server at connection setup.
  19 <!-- .KE -->
  20     </para>
  21   </glossdef>
  22 </glossentry>
  23 <glossentry id="glossary:Active_grab">
  24   <glossterm>Active grab</glossterm>
  25   <indexterm zone="glossary:Active_grab" significance="preferred"><primary>Active grab</primary></indexterm>
  26   <glossdef>
  27     <para>
  28 A grab is active when the pointer or keyboard is actually owned by
  29 the single grabbing client.
  30 <!-- .KE -->
  31     </para>
  32   </glossdef>
  33 </glossentry>
  34 <glossentry id="glossary:Ancestors">
  35   <glossterm>Ancestors</glossterm>
  36   <indexterm zone="glossary:Ancestors" significance="preferred"><primary>Ancestors</primary></indexterm>
  37   <glossdef>
  38     <para>
  39 If W is an <glossterm linkend="glossary:Inferiors">inferior</glossterm> of A, then A is an ancestor of W.
  40 <!-- .KE -->
  41     </para>
  42   </glossdef>
  43 </glossentry>
  44 <glossentry id="glossary:Atom">
  45   <glossterm>Atom</glossterm>
  46   <indexterm zone="glossary:Atom" significance="preferred"><primary>Atom</primary></indexterm>
  47   <glossdef>
  48     <para>
  49 An atom is a unique ID corresponding to a string name.
  50 Atoms are used to identify properties, types, and selections.
  51 <!-- .KE -->
  52     </para>
  53   </glossdef>
  54 </glossentry>
  55 <glossentry id="glossary:Background">
  56   <glossterm>Background</glossterm>
  57   <indexterm zone="glossary:Background" significance="preferred"><primary>Background</primary></indexterm>
  58   <glossdef>
  59     <para>
  60 An
  61 <glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
  62 window can have a background, which is defined as a pixmap.
  63 When regions of the window have their contents lost or invalidated,
  64 the server will automatically tile those regions with the background.
  65 <!-- .KE -->
  66     </para>
  67   </glossdef>
  68 </glossentry>
  69 <glossentry id="glossary:Backing_store">
  70   <glossterm>Backing store</glossterm>
  71   <indexterm zone="glossary:Backing_store" significance="preferred"><primary>Backing store</primary></indexterm>
  72   <glossdef>
  73     <para>
  74 When a server maintains the contents of a window,
  75 the pixels saved off screen are known as a backing store.
  76 <!-- .KE -->
  77     </para>
  78   </glossdef>
  79 </glossentry>
  80 <glossentry id="glossary:Bit_gravity">
  81   <glossterm>Bit gravity</glossterm>
  82   <indexterm zone="glossary:Bit_gravity" significance="preferred"><primary>Bit</primary><secondary>gravity</secondary></indexterm>
  83   <glossdef>
  84     <para>
  85 When a window is resized,
  86 the contents of the window are not necessarily discarded.
  87 It is possible to request that the server relocate the previous contents
  88 to some region of the window (though no guarantees are made).
  89 This attraction of window contents for some location of
  90 a window is known as bit gravity.
  91 <!-- .KE -->
  92     </para>
  93   </glossdef>
  94 </glossentry>
  95 <glossentry id="glossary:Bit_plane">
  96   <glossterm>Bit plane</glossterm>
  97   <indexterm zone="glossary:Bit_plane" significance="preferred"><primary>Bit</primary><secondary>plane</secondary></indexterm>
  98   <glossdef>
  99     <para>
 100 When a pixmap or window is thought of as a stack of bitmaps,
 101 each bitmap is called a bit plane or plane.
 102 <!-- .KE -->
 103     </para>
 104   </glossdef>
 105 </glossentry>
 106 <glossentry id="glossary:Bitmap">
 107   <glossterm>Bitmap</glossterm>
 108   <indexterm zone="glossary:Bitmap" significance="preferred"><primary>Bitmap</primary></indexterm>
 109   <glossdef>
 110     <para>
 111 A bitmap is a <glossterm linkend="glossary:Pixmap">pixmap</glossterm> of depth one.
 112 <!-- .KE -->
 113     </para>
 114   </glossdef>
 115 </glossentry>
 116 <glossentry id="glossary:Border">
 117   <glossterm>Border</glossterm>
 118   <indexterm zone="glossary:Border" significance="preferred"><primary>Border</primary></indexterm>
 119   <glossdef>
 120     <para>
 121 An
 122 <glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
 123 window can have a border of equal thickness on all four sides of the window.
 124 A pixmap defines the contents of the border,
 125 and the server automatically maintains the contents of the border.
 126 Exposure events are never generated for border regions.
 127 <!-- .KE -->
 128     </para>
 129   </glossdef>
 130 </glossentry>
 131 <glossentry id="glossary:Button_grabbing">
 132   <glossterm>Button grabbing</glossterm>
 133   <indexterm zone="glossary:Button_grabbing" significance="preferred"><primary>Button</primary><secondary>grabbing</secondary></indexterm>
 134   <glossdef>
 135     <para>
 136 Buttons on the pointer may be passively grabbed by a client.
 137 When the button is pressed,
 138 the pointer is then actively grabbed by the client.
 139 <!-- .KE -->
 140     </para>
 141   </glossdef>
 142 </glossentry>
 143 <glossentry id="glossary:Byte_order">
 144   <glossterm>Byte order</glossterm>
 145   <indexterm zone="glossary:Byte_order" significance="preferred"><primary>Byte order</primary></indexterm>
 146   <glossdef>
 147     <para>
 148 For image (pixmap/bitmap) data,
 149 the server defines the byte order,
 150 and clients with different native byte ordering must swap bytes as necessary.
 151 For all other parts of the protocol,
 152 the client defines the byte order,
 153 and the server swaps bytes as necessary.
 154 <!-- .KE -->
 155     </para>
 156   </glossdef>
 157 </glossentry>
 158 <glossentry id="glossary:Children">
 159   <glossterm>Children</glossterm>
 160   <indexterm zone="glossary:Children" significance="preferred"><primary>Children</primary></indexterm>
 161   <indexterm zone="glossary:Children" significance="preferred"><primary>Window</primary><secondary>children</secondary></indexterm>
 162   <glossdef>
 163     <para>
 164 The children of a window are its first-level subwindows.
 165 <!-- .KE -->
 166     </para>
 167   </glossdef>
 168 </glossentry>
 169 <glossentry id="glossary:Client">
 170   <glossterm>Client</glossterm>
 171   <indexterm zone="glossary:Client" significance="preferred"><primary>Client</primary></indexterm>
 172   <glossdef>
 173     <para>
 174 An application program connects to the window system server by some
 175 interprocess communication path, such as a TCP connection or a
 176 shared memory buffer.
 177 This program is referred to as a client of the window system server.
 178 More precisely,
 179 the client is the communication path itself;
 180 a program with multiple paths open to the server is viewed as
 181 multiple clients by the protocol.
 182 Resource lifetimes are controlled by connection lifetimes,
 183 not by program lifetimes.
 184 <!-- .KE -->
 185     </para>
 186   </glossdef>
 187 </glossentry>
 188 <glossentry id="glossary:Clipping_region">
 189   <glossterm>Clipping region</glossterm>
 190   <indexterm zone="glossary:Clipping_region" significance="preferred"><primary>Clipping region</primary></indexterm>
 191   <glossdef>
 192     <para>
 193 In a <glossterm linkend="glossary:Graphics_context">graphics context</glossterm>,
 194 a bitmap or list of rectangles can be specified
 195 to restrict output to a particular region of the window.
 196 The image defined by the bitmap or rectangles is called a clipping region.
 197 <!-- .KE -->
 198     </para>
 199   </glossdef>
 200 </glossentry>
 201 <glossentry id="glossary:Colormap">
 202   <glossterm>Colormap</glossterm>
 203   <indexterm zone="glossary:Colormap" significance="preferred"><primary>Colormap</primary></indexterm>
 204   <glossdef>
 205     <para>
 206 A colormap consists of a set of entries defining color values.
 207 The colormap associated with a window is used to display the contents of
 208 the window; each pixel value indexes the colormap to produce RGB values
 209 that drive the guns of a monitor.
 210 Depending on hardware limitations,
 211 one or more colormaps may be installed at one time,
 212 so that windows associated with those maps display with correct colors.
 213 <!-- .KE -->
 214     </para>
 215   </glossdef>
 216 </glossentry>
 217 <glossentry id="glossary:Connection">
 218   <glossterm>Connection</glossterm>
 219   <indexterm zone="glossary:Connection" significance="preferred"><primary>Connection</primary></indexterm>
 220   <glossdef>
 221     <para>
 222 The interprocess communication path between the server and client
 223 program is known as a connection.
 224 A client program typically (but not necessarily) has one
 225 connection to the server over which requests and events are sent.
 226 <!-- .KE -->
 227     </para>
 228   </glossdef>
 229 </glossentry>
 230 <glossentry id="glossary:Containment">
 231   <glossterm>Containment</glossterm>
 232   <indexterm zone="glossary:Containment" significance="preferred"><primary>Containment</primary></indexterm>
 233   <glossdef>
 234     <para>
 235 A window <quote>contains</quote> the pointer if the window is viewable and the
 236 <glossterm linkend="glossary:Hotspot">hotspot</glossterm> of the cursor is
 237 within a visible region of the window or a
 238 visible region of one of its inferiors.
 239 The border of the window is included as part of the window for containment.
 240 The pointer is <quote>in</quote> a window if the window contains the pointer
 241 but no inferior contains the pointer.
 242 <!-- .KE -->
 243     </para>
 244   </glossdef>
 245 </glossentry>
 246 <glossentry id="glossary:Coordinate_system">
 247   <glossterm>Coordinate system</glossterm>
 248   <indexterm zone="glossary:Coordinate_system" significance="preferred"><primary>Coordinate system</primary></indexterm>
 249   <glossdef>
 250     <para>
 251 The coordinate system has the X axis horizontal and the Y axis vertical,
 252 with the origin [0, 0] at the upper left.
 253 Coordinates are integral,
 254 in terms of pixels,
 255 and coincide with pixel centers.
 256 Each window and pixmap has its own coordinate system.
 257 For a window,
 258 the origin is inside the border at the inside upper left.
 259 <!-- .KE -->
 260     </para>
 261   </glossdef>
 262 </glossentry>
 263 <glossentry id="glossary:Cursor">
 264   <glossterm>Cursor</glossterm>
 265   <indexterm zone="glossary:Cursor" significance="preferred"><primary>Cursor</primary></indexterm>
 266   <glossdef>
 267     <para>
 268 A cursor is the visible shape of the pointer on a screen.
 269 It consists of a <glossterm linkend="glossary:Hotspot">hotspot</glossterm>,
 270 a source bitmap, a shape bitmap, and a pair of colors.
 271 The cursor defined for a window controls the visible appearance
 272 when the pointer is in that window.
 273 <!-- .KE -->
 274     </para>
 275   </glossdef>
 276 </glossentry>
 277 <glossentry id="glossary:Depth">
 278   <glossterm>Depth</glossterm>
 279   <indexterm zone="glossary:Depth" significance="preferred"><primary>Depth</primary></indexterm>
 280   <glossdef>
 281     <para>
 282 The depth of a window or pixmap is the number of bits per pixel that it has.
 283 The depth of a graphics context is the depth of the drawables it can be
 284 used in conjunction with for graphics output.
 285 <!-- .KE -->
 286     </para>
 287   </glossdef>
 288 </glossentry>
 289 <glossentry id="glossary:Device">
 290   <glossterm>Device</glossterm>
 291   <indexterm zone="glossary:Device" significance="preferred"><primary>Device</primary></indexterm>
 292   <glossdef>
 293     <para>
 294 Keyboards, mice, tablets, track-balls, button boxes, and so on are all
 295 collectively known as input devices.
 296 The core protocol only deals with two devices,
 297 <quote>the keyboard</quote> and <quote>the pointer.</quote>
 298 <!-- .KE -->
 299     </para>
 300   </glossdef>
 301 </glossentry>
 302 <glossentry id="glossary:DirectColor">
 303   <glossterm>DirectColor</glossterm>
 304   <indexterm zone="glossary:DirectColor" significance="preferred"><primary>DirectColor</primary></indexterm>
 305   <glossdef>
 306     <para>
 307 <emphasis role='bold'>DirectColor</emphasis>
 308 is a class of colormap in which a pixel value is decomposed into three
 309 separate subfields for indexing.
 310 The first subfield indexes an array to produce red intensity values.
 311 The second subfield indexes a second array to produce blue intensity values.
 312 The third subfield indexes a third array to produce green intensity values.
 313 The RGB values can be changed dynamically.
 314 <!-- .KE -->
 315     </para>
 316   </glossdef>
 317 </glossentry>
 318 <glossentry id="glossary:Display">
 319   <glossterm>Display</glossterm>
 320   <indexterm zone="glossary:Display" significance="preferred"><primary>Display</primary></indexterm>
 321   <glossdef>
 322     <para>
 323 A server, together with its screens and input devices, is called a display.
 324 <!-- .KE -->
 325     </para>
 326   </glossdef>
 327 </glossentry>
 328 <glossentry id="glossary:Drawable">
 329   <glossterm>Drawable</glossterm>
 330   <indexterm zone="glossary:Drawable" significance="preferred"><primary>Drawable</primary></indexterm>
 331   <glossdef>
 332     <para>
 333 Both windows and pixmaps can be used as sources and destinations in
 334 graphics operations.
 335 These windows and pixmaps are collectively known as drawables.
 336 However, an
 337 <glossterm linkend="glossary:InputOnly_window"><emphasis role='bold'>InputOnly</emphasis></glossterm>
 338 window cannot be used as a source or destination in a graphics operation.
 339 <!-- .KE -->
 340     </para>
 341   </glossdef>
 342 </glossentry>
 343 <glossentry id="glossary:Event">
 344   <glossterm>Event</glossterm>
 345   <indexterm zone="glossary:Event" significance="preferred"><primary>Event</primary></indexterm>
 346   <glossdef>
 347     <para>
 348 Clients are informed of information asynchronously by means of events.
 349 These events can be generated either asynchronously from devices
 350 or as side effects of client requests.
 351 Events are grouped into types.
 352 The server never sends events to a client unless the
 353 client has specificially asked to be informed of that type of event.
 354 However, other clients can force events to be sent to other clients.
 355 Events are typically reported relative to a window.
 356 <!-- .KE -->
 357     </para>
 358   </glossdef>
 359 </glossentry>
 360 <glossentry id="glossary:Event_mask">
 361   <glossterm>Event mask</glossterm>
 362   <indexterm zone="glossary:Event_mask" significance="preferred"><primary>Event</primary><secondary>mask</secondary></indexterm>
 363   <glossdef>
 364     <para>
 365 Events are requested relative to a window.
 366 The set of event types that a client requests relative to a window
 367 is described by using an event mask.
 368 <!-- .KE -->
 369     </para>
 370   </glossdef>
 371 </glossentry>
 372 <glossentry id="glossary:Event_synchronization">
 373   <glossterm>Event synchronization</glossterm>
 374   <indexterm zone="glossary:Event_synchronization" significance="preferred"><primary>Event</primary><secondary>synchronization</secondary></indexterm>
 375   <glossdef>
 376     <para>
 377 There are certain race conditions possible when demultiplexing device
 378 events to clients (in particular deciding where pointer and keyboard
 379 events should be sent when in the middle of window management
 380 operations).
 381 The event synchronization mechanism allows synchronous processing
 382 of device events.
 383 <!-- .KE -->
 384     </para>
 385   </glossdef>
 386 </glossentry>
 387 <glossentry id="glossary:Event_propagation">
 388   <glossterm>Event propagation</glossterm>
 389   <indexterm zone="glossary:Event_propagation" significance="preferred"><primary>Event</primary><secondary>propagation</secondary></indexterm>
 390   <glossdef>
 391     <para>
 392 Device-related events propagate from the source window to ancestor
 393 windows until some client has expressed interest in handling that type
 394 of event or until the event is discarded explicitly.
 395 <!-- .KE -->
 396     </para>
 397   </glossdef>
 398 </glossentry>
 399 <glossentry id="glossary:Event_source">
 400   <glossterm>Event source</glossterm>
 401   <indexterm zone="glossary:Event_source" significance="preferred"><primary>Event</primary><secondary>source</secondary></indexterm>
 402   <glossdef>
 403     <para>
 404 The window the pointer is in is the source of a device-related
 405 event.
 406 <!-- .KE -->
 407     </para>
 408   </glossdef>
 409 </glossentry>
 410 <glossentry id="glossary:Exposure_event">
 411   <glossterm>Exposure event</glossterm>
 412   <indexterm zone="glossary:Exposure_event" significance="preferred"><primary>Event</primary><secondary>Exposure</secondary></indexterm>
 413   <glossdef>
 414     <para>
 415 Servers do not guarantee to preserve the contents of windows when
 416 windows are obscured or reconfigured.
 417 Exposure events are sent to clients to inform them when contents
 418 of regions of windows have been lost.
 419 <!-- .KE -->
 420     </para>
 421   </glossdef>
 422 </glossentry>
 423 <glossentry id="glossary:Extension">
 424   <glossterm>Extension</glossterm>
 425   <indexterm zone="glossary:Extension" significance="preferred"><primary>Extension</primary></indexterm>
 426   <glossdef>
 427     <para>
 428 Named extensions to the core protocol can be defined to extend the
 429 system.
 430 Extension to output requests, resources, and event types are
 431 all possible and are expected.
 432 <!-- .KE -->
 433     </para>
 434   </glossdef>
 435 </glossentry>
 436 <glossentry id="glossary:Focus_window">
 437   <glossterm>Focus window</glossterm>
 438   <indexterm zone="glossary:Focus_window" significance="preferred"><primary>Focus window</primary></indexterm>
 439   <glossdef>
 440     <para>
 441 The focus window is another term for the <glossterm linkend="glossary:Input_focus">input focus</glossterm>.
 442 <!-- .KE -->
 443     </para>
 444   </glossdef>
 445 </glossentry>
 446 <glossentry id="glossary:Font">
 447   <glossterm>Font</glossterm>
 448   <indexterm zone="glossary:Font" significance="preferred"><primary>Font</primary></indexterm>
 449   <glossdef>
 450     <para>
 451 A font is a matrix of glyphs (typically characters).
 452 The protocol does no translation or interpretation of character sets.
 453 The client simply indicates values used to index the glyph array.
 454 A font contains additional metric information to determine interglyph
 455 and interline spacing.
 456 <!-- .KE -->
 457     </para>
 458   </glossdef>
 459 </glossentry>
 460 <glossentry id="glossary:GC">
 461   <glossterm>GC, GContext</glossterm>
 462   <indexterm zone="glossary:GC" significance="preferred"><primary>GC</primary><seealso>Graphics context</seealso></indexterm>
 463   <indexterm zone="glossary:GC" significance="preferred"><primary>GContext</primary><seealso>Graphics context</seealso></indexterm>
 464   <glossdef>
 465     <para>
 466 GC and gcontext are abbreviations for <glossterm linkend="glossary:Graphics_context">graphics context</glossterm>.
 467 <!-- .KE -->
 468     </para>
 469   </glossdef>
 470 </glossentry>
 471 <glossentry id="glossary:Glyph">
 472   <glossterm>Glyph</glossterm>
 473   <indexterm zone="glossary:Glyph" significance="preferred"><primary>Glyph</primary></indexterm>
 474   <glossdef>
 475     <para>
 476 A glyph is an image, typically of a character, in a font.
 477 <!-- .KE -->
 478     </para>
 479   </glossdef>
 480 </glossentry>
 481 <glossentry id="glossary:Grab">
 482   <glossterm>Grab</glossterm>
 483   <indexterm zone="glossary:Grab" significance="preferred"><primary>Grab</primary><seealso>Active grab</seealso><seealso>Passive grab</seealso></indexterm>
 484   <glossdef>
 485     <para>
 486 Keyboard keys, the keyboard, pointer buttons, the pointer, and the
 487 server can be grabbed for exclusive use by a client.
 488 In general,
 489 these facilities are not intended to be used by normal applications
 490 but are intended for various input and window managers to implement
 491 various styles of user interfaces.
 492 <!-- .KE -->
 493     </para>
 494   </glossdef>
 495 </glossentry>
 496 <glossentry id="glossary:Graphics_context">
 497   <glossterm>Graphics context</glossterm>
 498   <indexterm zone="glossary:Graphics_context" significance="preferred"><primary>Graphics context</primary></indexterm>
 499   <glossdef>
 500     <para>
 501 Various information for graphics output is stored in a graphics context
 502 such as foreground pixel, background pixel, line width,
 503 <glossterm linkend="glossary:Clipping_region">clipping region</glossterm>,
 504 and so on.
 505 A graphics context can only be used with drawables that have the same root
 506 and the same depth as the graphics context.
 507 <!-- .KE -->
 508     </para>
 509   </glossdef>
 510 </glossentry>
 511 <glossentry id="glossary:Gravity">
 512   <glossterm>Gravity</glossterm>
 513   <indexterm zone="glossary:Gravity" significance="preferred"><primary>Gravity</primary></indexterm>
 514   <glossdef>
 515     <para>
 516 See <glossterm linkend="glossary:Bit_gravity">bit gravity</glossterm>
 517 and <glossterm linkend="glossary:Window_gravity">window gravity</glossterm>.
 518 <!-- .KE -->
 519     </para>
 520   </glossdef>
 521 </glossentry>
 522 <glossentry id="glossary:GrayScale">
 523   <glossterm>GrayScale</glossterm>
 524   <indexterm zone="glossary:GrayScale" significance="preferred"><primary>GrayScale</primary></indexterm>
 525   <glossdef>
 526     <para>
 527 <emphasis role='bold'>GrayScale</emphasis>
 528 can be viewed as a degenerate case of
 529 <glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>,
 530 in which the red, green, and blue values in any given colormap entry are equal,
 531 thus producing shades of gray.
 532 The gray values can be changed dynamically.
 533 <!-- .KE -->
 534     </para>
 535   </glossdef>
 536 </glossentry>
 537 <glossentry id="glossary:Hotspot">
 538   <glossterm>Hotspot</glossterm>
 539   <indexterm zone="glossary:Hotspot" significance="preferred"><primary>Hotspot</primary></indexterm>
 540   <glossdef>
 541     <para>
 542 A cursor has an associated hotspot that defines the point in the
 543 cursor corresponding to the coordinates reported for the pointer.
 544 <!-- .KE -->
 545     </para>
 546   </glossdef>
 547 </glossentry>
 548 <glossentry id="glossary:Identifier">
 549   <glossterm>Identifier</glossterm>
 550   <indexterm zone="glossary:Identifier" significance="preferred"><primary>Identifier</primary></indexterm>
 551   <glossdef>
 552     <para>
 553 An identifier is a unique value associated with a resource that clients use
 554 to name that resource.
 555 The identifier can be used over any connection.
 556 <!-- .KE -->
 557     </para>
 558   </glossdef>
 559 </glossentry>
 560 <glossentry id="glossary:Inferiors">
 561   <glossterm>Inferiors</glossterm>
 562   <indexterm zone="glossary:Inferiors" significance="preferred"><primary>Inferiors</primary></indexterm>
 563   <glossdef>
 564     <para>
 565 The inferiors of a window are all of the subwindows nested below it:
 566 the children, the children's children, and so on.
 567 <!-- .KE -->
 568     </para>
 569   </glossdef>
 570 </glossentry>
 571 <glossentry id="glossary:Input_focus">
 572   <glossterm>Input focus</glossterm>
 573   <indexterm zone="glossary:Input_focus" significance="preferred"><primary>Input focus</primary></indexterm>
 574   <glossdef>
 575     <para>
 576 The input focus is normally a window defining the scope for
 577 processing of keyboard input.
 578 If a generated keyboard event would normally be reported to this window
 579 or one of its inferiors,
 580 the event is reported normally.
 581 Otherwise, the event is reported with respect to
 582 the focus window.
 583 The input focus also can be set such that all
 584 keyboard events are discarded and such that the focus
 585 window is dynamically taken to be the root window of whatever screen
 586 the pointer is on at each keyboard event.
 587 <!-- .KE -->
 588     </para>
 589   </glossdef>
 590 </glossentry>
 591 <glossentry id="glossary:Input_manager">
 592   <glossterm>Input manager</glossterm>
 593   <indexterm zone="glossary:Input_manager" significance="preferred"><primary>Input manager</primary></indexterm>
 594   <glossdef>
 595     <para>
 596 Control over keyboard input is typically provided by an input manager client.
 597 <!-- .KE -->
 598     </para>
 599   </glossdef>
 600 </glossentry>
 601 <glossentry id="glossary:InputOnly_window">
 602   <glossterm>InputOnly window</glossterm>
 603   <indexterm zone="glossary:InputOnly_window" significance="preferred"><primary>Window</primary><secondary>InputOnly</secondary></indexterm>
 604   <glossdef>
 605     <para>
 606 An
 607 <emphasis role='bold'>InputOnly</emphasis>
 608 window is a window that cannot be used for graphics requests.
 609 <emphasis role='bold'>InputOnly</emphasis>
 610 windows are invisible and can be used to control such things
 611 as cursors, input event generation, and grabbing.
 612 <emphasis role='bold'>InputOnly</emphasis>
 613 windows cannot have
 614 <emphasis role='bold'>InputOutput</emphasis>
 615 windows as inferiors.
 616 <!-- .KE -->
 617     </para>
 618   </glossdef>
 619 </glossentry>
 620 <glossentry id="glossary:InputOutput_window">
 621   <glossterm>InputOutput window</glossterm>
 622   <indexterm zone="glossary:InputOutput_window" significance="preferred"><primary>Window</primary><secondary>InputOutput</secondary></indexterm>
 623   <glossdef>
 624     <para>
 625 An
 626 <emphasis role='bold'>InputOutput</emphasis>
 627 window is the normal kind of opaque window, used for both input and output.
 628 <emphasis role='bold'>InputOutput</emphasis>
 629 windows can have both
 630 <emphasis role='bold'>InputOutput</emphasis>
 631 and
 632 <emphasis role='bold'>InputOnly</emphasis>
 633 windows as inferiors.
 634 <!-- .KE -->
 635     </para>
 636   </glossdef>
 637 </glossentry>
 638 <glossentry id="glossary:Key_grabbing">
 639   <glossterm>Key grabbing</glossterm>
 640   <indexterm zone="glossary:Key_grabbing" significance="preferred"><primary>Key</primary><secondary>grabbing</secondary></indexterm>
 641   <glossdef>
 642     <para>
 643 Keys on the keyboard can be passively grabbed by a client.
 644 When the key is pressed,
 645 the keyboard is then actively grabbed by the client.
 646 <!-- .KE -->
 647     </para>
 648   </glossdef>
 649 </glossentry>
 650 <glossentry id="glossary:Keyboard_grabbing">
 651   <glossterm>Keyboard grabbing</glossterm>
 652   <indexterm zone="glossary:Keyboard_grabbing" significance="preferred"><primary>Keyboard</primary><secondary>grabbing</secondary></indexterm>
 653   <glossdef>
 654     <para>
 655 A client can actively grab control of the keyboard, and key events
 656 will be sent to that client rather than the client the events would
 657 normally have been sent to.
 658 <!-- .KE -->
 659     </para>
 660   </glossdef>
 661 </glossentry>
 662 <glossentry id="glossary:Keysym">
 663   <glossterm>Keysym</glossterm>
 664   <indexterm zone="glossary:Keysym" significance="preferred"><primary>Keysym</primary></indexterm>
 665   <glossdef>
 666     <para>
 667 An encoding of a symbol on a keycap on a keyboard.
 668 <!-- .KE -->
 669     </para>
 670   </glossdef>
 671 </glossentry>
 672 <glossentry id="glossary:Mapped">
 673   <glossterm>Mapped</glossterm>
 674   <indexterm zone="glossary:Mapped" significance="preferred"><primary>Mapped window</primary></indexterm>
 675   <glossdef>
 676     <para>
 677 A window is said to be mapped if a map call has been performed on it.
 678 Unmapped windows and their inferiors are never viewable or visible.
 679 <!-- .KE -->
 680     </para>
 681   </glossdef>
 682 </glossentry>
 683 <glossentry id="glossary:Modifier_keys">
 684   <glossterm>Modifier keys</glossterm>
 685   <indexterm zone="glossary:Modifier_keys" significance="preferred"><primary>Modifier keys</primary></indexterm>
 686   <indexterm zone="glossary:Modifier_keys"><primary>Key</primary><secondary>modifier</secondary><see>Modifier keys</see></indexterm>
 687   <glossdef>
 688     <para>
 689 Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
 690 ShiftLock, and similar keys are called modifier keys.
 691 <!-- .KE -->
 692     </para>
 693   </glossdef>
 694 </glossentry>
 695 <glossentry id="glossary:Monochrome">
 696   <glossterm>Monochrome</glossterm>
 697   <indexterm zone="glossary:Monochrome" significance="preferred"><primary>Monochrome</primary></indexterm>
 698   <glossdef>
 699     <para>
 700 Monochrome is a special case of
 701 <glossterm linkend="glossary:StaticGray"><emphasis role='bold'>StaticGray</emphasis></glossterm>
 702 in which there are only two colormap entries.
 703 <!-- .KE -->
 704     </para>
 705   </glossdef>
 706 </glossentry>
 707 <glossentry id="glossary:Obscure">
 708   <glossterm>Obscure</glossterm>
 709   <indexterm zone="glossary:Obscure" significance="preferred"><primary>Obscure</primary></indexterm>
 710   <glossdef>
 711     <para>
 712 A window is obscured if some other window obscures it.
 713 Window A obscures window B if both are viewable
 714 <glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
 715 windows, A is higher in the global stacking order,
 716 and the rectangle defined by the outside edges of A intersects
 717 the rectangle defined by the outside edges of B.
 718 Note the distinction between obscure and occludes.
 719 Also note that window borders are included in the calculation
 720 and that a window can be obscured and yet still have visible regions.
 721 <!-- .KE -->
 722     </para>
 723   </glossdef>
 724 </glossentry>
 725 <glossentry id="glossary:Occlude">
 726   <glossterm>Occlude</glossterm>
 727   <indexterm zone="glossary:Occlude" significance="preferred"><primary>Occlude</primary></indexterm>
 728   <glossdef>
 729     <para>
 730 A window is occluded if some other window occludes it.
 731 Window A occludes window B if both are mapped, A is higher in the global
 732 stacking order, and the rectangle defined by the outside edges of A
 733 intersects the rectangle defined by the outside edges of B.
 734 Note the distinction between occludes and obscures.
 735 Also note that window borders are included in the calculation.
 736 <!-- .KE -->
 737     </para>
 738   </glossdef>
 739 </glossentry>
 740 <glossentry id="glossary:Padding">
 741   <glossterm>Padding</glossterm>
 742   <indexterm zone="glossary:Padding" significance="preferred"><primary>Padding</primary></indexterm>
 743   <glossdef>
 744     <para>
 745 Some padding bytes are inserted in the data stream to maintain
 746 alignment of the protocol requests on natural boundaries.
 747 This increases ease of portability to some machine architectures.
 748 <!-- .KE -->
 749     </para>
 750   </glossdef>
 751 </glossentry>
 752 <glossentry id="glossary:Parent_window">
 753   <glossterm>Parent window</glossterm>
 754   <indexterm zone="glossary:Parent_window" significance="preferred"><primary>Window</primary><secondary>parent</secondary></indexterm>
 755   <glossdef>
 756     <para>
 757 If C is a <glossterm linkend="glossary:Children">child</glossterm> of P,
 758 then P is the parent of C.
 759 <!-- .KE -->
 760     </para>
 761   </glossdef>
 762 </glossentry>
 763 <glossentry id="glossary:Passive_grab">
 764   <glossterm>Passive grab</glossterm>
 765   <indexterm zone="glossary:Passive_grab" significance="preferred"><primary>Passive grab</primary></indexterm>
 766   <glossdef>
 767     <para>
 768 Grabbing a key or button is a passive grab.
 769 The grab activates when the key or button is actually pressed.
 770 <!-- .KE -->
 771     </para>
 772   </glossdef>
 773 </glossentry>
 774 <glossentry id="glossary:Pixel_value">
 775   <glossterm>Pixel value</glossterm>
 776   <indexterm zone="glossary:Pixel_value" significance="preferred"><primary>Pixel value</primary></indexterm>
 777   <glossdef>
 778     <para>
 779 A pixel is an N-bit value, where N is the number of bit planes used
 780 in a particular window or pixmap (that is,
 781 N is the depth of the window or pixmap).
 782 For a window,
 783 a pixel value indexes a colormap to derive an actual color to be displayed.
 784 <!-- .KE -->
 785     </para>
 786   </glossdef>
 787 </glossentry>
 788 <glossentry id="glossary:Pixmap">
 789   <glossterm>Pixmap</glossterm>
 790   <indexterm zone="glossary:Pixmap" significance="preferred"><primary>Pixmap</primary></indexterm>
 791   <glossdef>
 792     <para>
 793 A pixmap is a three-dimensional array of bits.
 794 A pixmap is normally thought of as a two-dimensional array of pixels,
 795 where each pixel can be a value from 0 to (2^N)-1
 796 and where N is the depth (z axis) of the pixmap.
 797 A pixmap can also be thought of as a stack of N bitmaps.
 798 <!-- .KE -->
 799     </para>
 800   </glossdef>
 801 </glossentry>
 802 <glossentry id="glossary:Plane">
 803   <glossterm>Plane</glossterm>
 804   <indexterm zone="glossary:Plane" significance="preferred"><primary>Plane</primary></indexterm>
 805   <glossdef>
 806     <para>
 807 When a pixmap or window is thought of as a stack of bitmaps,
 808 each bitmap is called a plane or bit plane.
 809 <!-- .KE -->
 810     </para>
 811   </glossdef>
 812 </glossentry>
 813 <glossentry id="glossary:Plane_mask">
 814   <glossterm>Plane mask</glossterm>
 815   <indexterm zone="glossary:Plane_mask" significance="preferred"><primary>Plane</primary><secondary>mask</secondary></indexterm>
 816   <glossdef>
 817     <para>
 818 Graphics operations can be restricted to only affect a subset of bit
 819 planes of a destination.
 820 A plane mask is a bit mask describing which planes are to be modified.
 821 The plane mask is stored in a graphics context.
 822 <!-- .KE -->
 823     </para>
 824   </glossdef>
 825 </glossentry>
 826 <glossentry id="glossary:Pointer">
 827   <glossterm>Pointer</glossterm>
 828   <indexterm zone="glossary:Pointer" significance="preferred"><primary>Pointer</primary></indexterm>
 829   <glossdef>
 830     <para>
 831 The pointer is the pointing device attached to the cursor
 832 and tracked on the screens.
 833 <!-- .KE -->
 834     </para>
 835   </glossdef>
 836 </glossentry>
 837 <glossentry id="glossary:Pointer_grabbing">
 838   <glossterm>Pointer grabbing</glossterm>
 839   <indexterm zone="glossary:Pointer_grabbing" significance="preferred"><primary>Pointer</primary><secondary>grabbing</secondary></indexterm>
 840   <glossdef>
 841     <para>
 842 A client can actively grab control of the pointer.
 843 Then button and motion events will be sent to that client
 844 rather than the client the events would normally have been sent to.
 845 <!-- .KE -->
 846     </para>
 847   </glossdef>
 848 </glossentry>
 849 <glossentry id="glossary:Pointing_device">
 850   <glossterm>Pointing device</glossterm>
 851   <indexterm zone="glossary:Pointing_device" significance="preferred"><primary>Pointing device</primary></indexterm>
 852   <glossdef>
 853     <para>
 854 A pointing device is typically a mouse, tablet, or some other
 855 device with effective dimensional motion.
 856 There is only one visible cursor defined by the core protocol,
 857 and it tracks whatever pointing device is attached as the pointer.
 858 <!-- .KE -->
 859     </para>
 860   </glossdef>
 861 </glossentry>
 862 <glossentry id="glossary:Property">
 863   <glossterm>Property</glossterm>
 864   <indexterm zone="glossary:Property" significance="preferred"><primary>Property</primary></indexterm>
 865   <glossdef>
 866     <para>
 867 Windows may have associated properties,
 868 which consist of a name, a type, a data format, and some data.
 869 The protocol places no interpretation on properties.
 870 They are intended as a general-purpose naming mechanism for clients.
 871 For example, clients might use properties to share information such as resize
 872 hints, program names, and icon formats with a window manager.
 873 <!-- .KE -->
 874     </para>
 875   </glossdef>
 876 </glossentry>
 877 <glossentry id="glossary:Property_list">
 878   <glossterm>Property list</glossterm>
 879   <indexterm zone="glossary:Property_list" significance="preferred"><primary>Property list</primary></indexterm>
 880   <glossdef>
 881     <para>
 882 The property list of a window is the list of properties that have
 883 been defined for the window.
 884 <!-- .KE -->
 885     </para>
 886   </glossdef>
 887 </glossentry>
 888 <glossentry id="glossary:PseudoColor">
 889   <glossterm>PseudoColor</glossterm>
 890   <indexterm zone="glossary:PseudoColor" significance="preferred"><primary>PseudoColor</primary></indexterm>
 891   <glossdef>
 892     <para>
 893 <emphasis role='bold'>PseudoColor</emphasis>
 894 is a class of colormap in which a pixel value indexes the colormap to
 895 produce independent red, green, and blue values;
 896 that is, the colormap is viewed as an array of triples (RGB values).
 897 The RGB values can be changed dynamically.
 898 <!-- .KE -->
 899     </para>
 900   </glossdef>
 901 </glossentry>
 902 <glossentry id="glossary:Redirecting_control">
 903   <glossterm>Redirecting control</glossterm>
 904   <indexterm zone="glossary:Redirecting_control" significance="preferred"><primary>Redirecting control</primary></indexterm>
 905   <glossdef>
 906     <para>
 907 Window managers (or client programs) may want to enforce window layout
 908 policy in various ways.
 909 When a client attempts to change the size or position of a window,
 910 the operation may be redirected to a specified client
 911 rather than the operation actually being performed.
 912 <!-- .KE -->
 913     </para>
 914   </glossdef>
 915 </glossentry>
 916 <glossentry id="glossary:Reply">
 917   <glossterm>Reply</glossterm>
 918   <indexterm zone="glossary:Reply" significance="preferred"><primary>Reply</primary></indexterm>
 919   <glossdef>
 920     <para>
 921 Information requested by a client program is sent back to the client
 922 with a reply.
 923 Both events and replies are multiplexed on the same connection.
 924 Most requests do not generate replies,
 925 although some requests generate multiple replies.
 926 <!-- .KE -->
 927     </para>
 928   </glossdef>
 929 </glossentry>
 930 <glossentry id="glossary:Request">
 931   <glossterm>Request</glossterm>
 932   <indexterm zone="glossary:Request" significance="preferred"><primary>Request</primary></indexterm>
 933   <glossdef>
 934     <para>
 935 A command to the server is called a request.
 936 It is a single block of data sent over a connection.
 937 <!-- .KE -->
 938     </para>
 939   </glossdef>
 940 </glossentry>
 941 <glossentry id="glossary:Resource">
 942   <glossterm>Resource</glossterm>
 943   <indexterm zone="glossary:Resource" significance="preferred"><primary>Resource</primary></indexterm>
 944   <glossdef>
 945     <para>
 946 Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
 947 known as resources.
 948 They all have unique identifiers associated with them for naming purposes.
 949 The lifetime of a resource usually is bounded by the lifetime of the connection
 950 over which the resource was created.
 951 <!-- .KE -->
 952     </para>
 953   </glossdef>
 954 </glossentry>
 955 <glossentry id="glossary:RGB_values">
 956   <glossterm>RGB values</glossterm>
 957   <indexterm zone="glossary:RGB_values" significance="preferred"><primary>RGB values</primary></indexterm>
 958   <glossdef>
 959     <para>
 960 Red, green, and blue (RGB) intensity values are used to define color.
 961 These values are always represented as 16-bit unsigned numbers,
 962 with 0 being the minimum intensity and 65535 being the maximum intensity.
 963 The server scales the values to match the display hardware.
 964 <!-- .KE -->
 965     </para>
 966   </glossdef>
 967 </glossentry>
 968 <glossentry id="glossary:Root">
 969   <glossterm>Root</glossterm>
 970   <indexterm zone="glossary:Root" significance="preferred"><primary>Root</primary></indexterm>
 971   <glossdef>
 972     <para>
 973 The root of a pixmap, colormap, or graphics context is the same as the root of
 974 whatever drawable was used when the pixmap, colormap, or graphics context was
 975 created.
 976 The root of a window is the root window under which the window was created.
 977 <!-- .KE -->
 978     </para>
 979   </glossdef>
 980 </glossentry>
 981 <glossentry id="glossary:Root_window">
 982   <glossterm>Root window</glossterm>
 983   <indexterm zone="glossary:Root_window" significance="preferred"><primary>Window</primary><secondary>root</secondary></indexterm>
 984   <glossdef>
 985     <para>
 986 Each screen has a root window covering it.
 987 It cannot be reconfigured or unmapped,
 988 but it otherwise acts as a full-fledged window.
 989 A root window has no parent.
 990 <!-- .KE -->
 991     </para>
 992   </glossdef>
 993 </glossentry>
 994 <glossentry id="glossary:Save_set">
 995   <glossterm>Save set</glossterm>
 996   <indexterm zone="glossary:Save_set" significance="preferred"><primary>Save set</primary></indexterm>
 997   <glossdef>
 998     <para>
 999 The save set of a client is a list of other clients' windows that,
1000 if they are inferiors of one of the client's windows at connection close,
1001 should not be destroyed and that should be remapped if currently unmapped.
1002 Save sets are typically used by window managers to avoid
1003 lost windows if the manager terminates abnormally.
1004 <!-- .KE -->
1005     </para>
1006   </glossdef>
1007 </glossentry>
1008 <glossentry id="glossary:Scanline">
1009   <glossterm>Scanline</glossterm>
1010   <indexterm zone="glossary:Scanline" significance="preferred"><primary>Scanline</primary></indexterm>
1011   <glossdef>
1012     <para>
1013 A scanline is a list of pixel or bit values viewed as a horizontal
1014 row (all values having the same y coordinate) of an image, with the
1015 values ordered by increasing x coordinate.
1016 <!-- .KE -->
1017     </para>
1018   </glossdef>
1019 </glossentry>
1020 <glossentry id="glossary:Scanline_order">
1021   <glossterm>Scanline order</glossterm>
1022   <indexterm zone="glossary:Scanline_order" significance="preferred"><primary>Scanline order</primary></indexterm>
1023   <glossdef>
1024     <para>
1025 An image represented in scanline order contains scanlines ordered by
1026 increasing y coordinate.
1027 <!-- .KE -->
1028     </para>
1029   </glossdef>
1030 </glossentry>
1031 <glossentry id="glossary:Screen">
1032   <glossterm>Screen</glossterm>
1033   <indexterm zone="glossary:Screen" significance="preferred"><primary>Screen</primary></indexterm>
1034   <glossdef>
1035     <para>
1036 A server can provide several independent screens,
1037 which typically have physically independent monitors.
1038 This would be the expected configuration when there is only a single keyboard
1039 and pointer shared among the screens.
1040 <!-- .KE -->
1041     </para>
1042   </glossdef>
1043 </glossentry>
1044 <glossentry id="glossary:Selection">
1045   <glossterm>Selection</glossterm>
1046   <indexterm zone="glossary:Selection" significance="preferred"><primary>Selection</primary></indexterm>
1047   <glossdef>
1048     <para>
1049 A selection can be thought of as an indirect property with dynamic
1050 type; that is, rather than having the property stored in the server,
1051 it is maintained by some client (the <quote>owner</quote>).
1052 A selection is global in nature and is thought of as belonging to the user
1053 (although maintained by clients), rather than as being private to a particular
1054 window subhierarchy or a particular set of clients.
1055 When a client asks for the contents of a selection,
1056 it specifies a selection <quote>target type</quote>.
1057 This target type can be used to control the transmitted representation of the
1058 contents.
1059 For example,
1060 if the selection is <quote>the last thing the user clicked on</quote>
1061 and that is currently an image, then the target type might specify
1062 whether the contents of the image should be sent in XY format or Z format.
1063 The target type can also be used to control the class of contents transmitted;
1064 for example, asking for the <quote>looks</quote> (fonts, line
1065 spacing, indentation, and so on) of a paragraph selection rather than the
1066 text of the paragraph.
1067 The target type can also be used for other purposes.
1068 The protocol does not constrain the semantics.
1069 <!-- .KE -->
1070     </para>
1071   </glossdef>
1072 </glossentry>
1073 <glossentry id="glossary:Server">
1074   <glossterm>Server</glossterm>
1075   <indexterm zone="glossary:Server" significance="preferred"><primary>Server</primary></indexterm>
1076   <glossdef>
1077     <para>
1078 The server provides the basic windowing mechanism.
1079 It handles connections from clients,
1080 multiplexes graphics requests onto the screens,
1081 and demultiplexes input back to the appropriate clients.
1082 <!-- .KE -->
1083     </para>
1084   </glossdef>
1085 </glossentry>
1086 <glossentry id="glossary:Server_grabbing">
1087   <glossterm>Server grabbing</glossterm>
1088   <indexterm zone="glossary:Server_grabbing" significance="preferred"><primary>Server</primary><secondary>grabbing</secondary></indexterm>
1089   <glossdef>
1090     <para>
1091 The server can be grabbed by a single client for exclusive use.
1092 This prevents processing of any requests from other client connections until
1093 the grab is completed.
1094 This is typically only a transient state for
1095 such things as rubber-banding, pop-up menus, or to execute requests
1096 indivisibly.
1097 <!-- .KE -->
1098     </para>
1099   </glossdef>
1100 </glossentry>
1101 <glossentry id="glossary:Sibling">
1102   <glossterm>Sibling</glossterm>
1103   <indexterm zone="glossary:Sibling" significance="preferred"><primary>Sibling</primary></indexterm>
1104   <glossdef>
1105     <para>
1106 Children of the same parent window are known as sibling windows.
1107 <!-- .KE -->
1108     </para>
1109   </glossdef>
1110 </glossentry>
1111 <glossentry id="glossary:Stacking_order">
1112   <glossterm>Stacking order</glossterm>
1113   <indexterm zone="glossary:Stacking_order" significance="preferred"><primary>Stacking order</primary></indexterm>
1114   <glossdef>
1115     <para>
1116 Sibling windows may stack on top of each other.
1117 Windows above other windows both obscure and occlude those lower windows.
1118 This is similar to paper on a desk.
1119 The relationship between sibling windows is known as the stacking order.
1120 <!-- .KE -->
1121     </para>
1122   </glossdef>
1123 </glossentry>
1124 <glossentry id="glossary:StaticColor">
1125   <glossterm>StaticColor</glossterm>
1126   <indexterm zone="glossary:StaticColor" significance="preferred"><primary>StaticColor</primary></indexterm>
1127   <glossdef>
1128     <para>
1129 <emphasis role='bold'>StaticColor</emphasis>
1130 can be viewed as a degenerate case of
1131 <glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>
1132 in which the RGB values are predefined and read-only.
1133 <!-- .KE -->
1134     </para>
1135   </glossdef>
1136 </glossentry>
1137 <glossentry id="glossary:StaticGray">
1138   <glossterm>StaticGray</glossterm>
1139   <indexterm zone="glossary:StaticGray" significance="preferred"><primary>StaticGray</primary></indexterm>
1140   <glossdef>
1141     <para>
1142 <emphasis role='bold'>StaticGray</emphasis>
1143 can be viewed as a degenerate case of
1144 <glossterm linkend="glossary:GrayScale"><emphasis role='bold'>GrayScale</emphasis></glossterm>
1145 in which the gray values are predefined and read-only.
1146 The values are typically linear or near-linear increasing ramps.
1147 <!-- .KE -->
1148     </para>
1149   </glossdef>
1150 </glossentry>
1151 <glossentry id="glossary:Stipple">
1152   <glossterm>Stipple</glossterm>
1153   <indexterm zone="glossary:Stipple" significance="preferred"><primary>Stipple</primary></indexterm>
1154   <glossdef>
1155     <para>
1156 A stipple pattern is a bitmap that is used to tile a region that will serve
1157 as an additional clip mask for a fill operation with the foreground
1158 color.
1159 <!-- .KE -->
1160     </para>
1161   </glossdef>
1162 </glossentry>
1163 <glossentry id="glossary:String_Equivalence">
1164   <glossterm>String Equivalence</glossterm>
1165   <indexterm zone="glossary:String_Equivalence" significance="preferred"><primary>String Equivalence</primary></indexterm>
1166   <glossdef>
1167     <para>
1168 Two ISO Latin-1 STRING8 values are considered equal if they are the same
1169 length and if corresponding bytes are either equal or are equivalent as
1170 follows:  decimal values 65 to 90 inclusive (characters <quote>A</quote> to <quote>Z</quote>) are
1171 pairwise equivalent to decimal values 97 to 122 inclusive
1172 (characters <quote>a</quote> to <quote>z</quote>), decimal values 192 to 214 inclusive
1173 (characters <quote>A grave</quote> to <quote>O diaeresis</quote>) are pairwise equivalent to decimal
1174 values 224 to 246 inclusive (characters <quote>a grave</quote> to <quote>o diaeresis</quote>),
1175 and decimal values 216 to 222 inclusive (characters <quote>O oblique</quote> to <quote>THORN</quote>)
1176 are pairwise equivalent to decimal values 246 to 254 inclusive
1177 (characters <quote>o oblique</quote> to <quote>thorn</quote>).
1178 <!-- .KE -->
1179     </para>
1180   </glossdef>
1181 </glossentry>
1182 <glossentry id="glossary:Tile">
1183   <glossterm>Tile</glossterm>
1184   <indexterm zone="glossary:Tile" significance="preferred"><primary>Tile</primary></indexterm>
1185   <glossdef>
1186     <para>
1187 A pixmap can be replicated in two dimensions to tile a region.
1188 The pixmap itself is also known as a tile.
1189 <!-- .KE -->
1190     </para>
1191   </glossdef>
1192 </glossentry>
1193 <glossentry id="glossary:Timestamp">
1194   <glossterm>Timestamp</glossterm>
1195   <indexterm zone="glossary:Timestamp" significance="preferred"><primary>Timestamp</primary></indexterm>
1196   <indexterm zone="glossary:Timestamp" significance="preferred"><primary>CurrentTime</primary></indexterm>
1197   <glossdef>
1198     <para>
1199 A timestamp is a time value, expressed in milliseconds.
1200 It typically is the time since the last
1201 server reset.
1202 Timestamp values wrap around (after about 49.7 days).
1203 The server, given its current time is represented by timestamp T,
1204 always interprets timestamps from clients by treating half of the
1205 timestamp space as being earlier in time than T and half of the
1206 timestamp space as being later in time than T.
1207 One timestamp value (named
1208 <emphasis role='bold'>CurrentTime</emphasis>)
1209 is never generated by the server.
1210 This value is reserved for use in requests to represent the current
1211 server time.
1212 <!-- .KE -->
1213     </para>
1214   </glossdef>
1215 </glossentry>
1216 <glossentry id="glossary:TrueColor">
1217   <glossterm>TrueColor</glossterm>
1218   <indexterm zone="glossary:TrueColor" significance="preferred"><primary>TrueColor</primary></indexterm>
1219   <glossdef>
1220     <para>
1221 <emphasis role='bold'>TrueColor</emphasis>
1222 can be viewed as a degenerate case of
1223 <glossterm linkend="glossary:DirectColor"><emphasis role='bold'>DirectColor</emphasis></glossterm>
1224 in which the subfields in the pixel value directly encode
1225 the corresponding RGB values; that is, the colormap has predefined
1226 read-only RGB values.
1227 The values are typically linear or near-linear increasing ramps.
1228 <!-- .KE -->
1229     </para>
1230   </glossdef>
1231 </glossentry>
1232 <glossentry id="glossary:Type">
1233   <glossterm>Type</glossterm>
1234   <indexterm zone="glossary:Type" significance="preferred"><primary>Type</primary></indexterm>
1235   <glossdef>
1236     <para>
1237 A type is an arbitrary atom used to identify the interpretation of
1238 property data.
1239 Types are completely uninterpreted by the server
1240 and are solely for the benefit of clients.
1241 <!-- .KE -->
1242     </para>
1243   </glossdef>
1244 </glossentry>
1245 <glossentry id="glossary:Viewable">
1246   <glossterm>Viewable</glossterm>
1247   <indexterm zone="glossary:Viewable" significance="preferred"><primary>Viewable</primary></indexterm>
1248   <glossdef>
1249     <para>
1250 A window is viewable if it and all of its ancestors are mapped.
1251 This does not imply that any portion of the window is actually visible.
1252 Graphics requests can be performed on a window when it is not viewable,
1253 but output will not be retained unless the server is maintaining
1254 backing store.
1255 <!-- .KE -->
1256     </para>
1257   </glossdef>
1258 </glossentry>
1259 <glossentry id="glossary:Visible">
1260   <glossterm>Visible</glossterm>
1261   <indexterm zone="glossary:Visible" significance="preferred"><primary>Visible</primary></indexterm>
1262   <glossdef>
1263     <para>
1264 A region of a window is visible if someone looking at the screen can
1265 actually see it;
1266 that is, the window is viewable and the region is not occluded by any
1267 other window.
1268 <!-- .KE -->
1269     </para>
1270   </glossdef>
1271 </glossentry>
1272 <glossentry id="glossary:Window_gravity">
1273   <glossterm>Window gravity</glossterm>
1274   <indexterm zone="glossary:Window_gravity" significance="preferred"><primary>Window</primary><secondary>gravity</secondary></indexterm>
1275   <glossdef>
1276     <para>
1277 When windows are resized,
1278 subwindows may be repositioned automatically relative to some position
1279 in the window.
1280 This attraction of a subwindow to some part of its parent is known
1281 as window gravity.
1282 <!-- .KE -->
1283     </para>
1284   </glossdef>
1285 </glossentry>
1286 <glossentry id="glossary:Window_manager">
1287   <glossterm>Window manager</glossterm>
1288   <indexterm zone="glossary:Window_manager" significance="preferred"><primary>Window</primary><secondary>manager</secondary></indexterm>
1289   <glossdef>
1290     <para>
1291 Manipulation of windows on the screen and much of the user interface
1292 (policy) is typically provided by a window manager client.
1293 <!-- .KE -->
1294     </para>
1295   </glossdef>
1296 </glossentry>
1297 <glossentry id="glossary:XYFormat">
1298   <glossterm>XYFormat</glossterm>
1299   <indexterm zone="glossary:XYFormat" significance="preferred"><primary>XYFormat</primary></indexterm>
1300   <glossdef>
1301     <para>
1302 The data for a pixmap is said to be in XY format if it is organized as
1303 a set of bitmaps representing individual bit planes, with the planes
1304 appearing from most-significant to least-significant in bit order.
1305 <!-- .KE -->
1306     </para>
1307   </glossdef>
1308 </glossentry>
1309 <glossentry id="glossary:ZFormat">
1310   <glossterm>ZFormat</glossterm>
1311   <indexterm zone="glossary:ZFormat" significance="preferred"><primary>ZFormat</primary></indexterm>
1312   <glossdef>
1313     <para>
1314 The data for a pixmap is said to be in Z format if it is organized as
1315 a set of pixel values in scanline order.
1316 <!-- .KE -->
1317     </para>
1318   </glossdef>
1319 </glossentry>
1320 </glossary>