File: glossary.xml

package info (click to toggle)
x11proto-core 7.0.26-1
  • links: PTS, VCS
  • area: main
  • in suites: jessie, jessie-kfreebsd
  • size: 2,104 kB
  • ctags: 5,455
  • sloc: xml: 24,340; ansic: 5,905; sh: 3,674; cpp: 397; makefile: 69
file content (1320 lines) | stat: -rw-r--r-- 49,732 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
<glossary id='glossary'>
<title>Glossary</title>


<glossentry id="glossary:Access_control_list">
  <glossterm>Access control list</glossterm>
  <indexterm zone="glossary:Access_control_list" significance="preferred"><primary>Access control list</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Active_grab">
  <glossterm>Active grab</glossterm>
  <indexterm zone="glossary:Active_grab" significance="preferred"><primary>Active grab</primary></indexterm>
  <glossdef>
    <para>
A grab is active when the pointer or keyboard is actually owned by
the single grabbing client.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Ancestors">
  <glossterm>Ancestors</glossterm>
  <indexterm zone="glossary:Ancestors" significance="preferred"><primary>Ancestors</primary></indexterm>
  <glossdef>
    <para>
If W is an <glossterm linkend="glossary:Inferiors">inferior</glossterm> of A, then A is an ancestor of W.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Atom">
  <glossterm>Atom</glossterm>
  <indexterm zone="glossary:Atom" significance="preferred"><primary>Atom</primary></indexterm>
  <glossdef>
    <para>
An atom is a unique ID corresponding to a string name.
Atoms are used to identify properties, types, and selections.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Background">
  <glossterm>Background</glossterm>
  <indexterm zone="glossary:Background" significance="preferred"><primary>Background</primary></indexterm>
  <glossdef>
    <para>
An
<glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Backing_store">
  <glossterm>Backing store</glossterm>
  <indexterm zone="glossary:Backing_store" significance="preferred"><primary>Backing store</primary></indexterm>
  <glossdef>
    <para>
When a server maintains the contents of a window,
the pixels saved off screen are known as a backing store.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Bit_gravity">
  <glossterm>Bit gravity</glossterm>
  <indexterm zone="glossary:Bit_gravity" significance="preferred"><primary>Bit</primary><secondary>gravity</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Bit_plane">
  <glossterm>Bit plane</glossterm>
  <indexterm zone="glossary:Bit_plane" significance="preferred"><primary>Bit</primary><secondary>plane</secondary></indexterm>
  <glossdef>
    <para>
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a bit plane or plane.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Bitmap">
  <glossterm>Bitmap</glossterm>
  <indexterm zone="glossary:Bitmap" significance="preferred"><primary>Bitmap</primary></indexterm>
  <glossdef>
    <para>
A bitmap is a <glossterm linkend="glossary:Pixmap">pixmap</glossterm> of depth one.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Border">
  <glossterm>Border</glossterm>
  <indexterm zone="glossary:Border" significance="preferred"><primary>Border</primary></indexterm>
  <glossdef>
    <para>
An
<glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Button_grabbing">
  <glossterm>Button grabbing</glossterm>
  <indexterm zone="glossary:Button_grabbing" significance="preferred"><primary>Button</primary><secondary>grabbing</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Byte_order">
  <glossterm>Byte order</glossterm>
  <indexterm zone="glossary:Byte_order" significance="preferred"><primary>Byte order</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Children">
  <glossterm>Children</glossterm>
  <indexterm zone="glossary:Children" significance="preferred"><primary>Children</primary></indexterm>
  <indexterm zone="glossary:Children" significance="preferred"><primary>Window</primary><secondary>children</secondary></indexterm>
  <glossdef>
    <para>
The children of a window are its first-level subwindows.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Client">
  <glossterm>Client</glossterm>
  <indexterm zone="glossary:Client" significance="preferred"><primary>Client</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Clipping_region">
  <glossterm>Clipping region</glossterm>
  <indexterm zone="glossary:Clipping_region" significance="preferred"><primary>Clipping region</primary></indexterm>
  <glossdef>
    <para>
In a <glossterm linkend="glossary:Graphics_context">graphics context</glossterm>,
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Colormap">
  <glossterm>Colormap</glossterm>
  <indexterm zone="glossary:Colormap" significance="preferred"><primary>Colormap</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Connection">
  <glossterm>Connection</glossterm>
  <indexterm zone="glossary:Connection" significance="preferred"><primary>Connection</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Containment">
  <glossterm>Containment</glossterm>
  <indexterm zone="glossary:Containment" significance="preferred"><primary>Containment</primary></indexterm>
  <glossdef>
    <para>
A window <quote>contains</quote> the pointer if the window is viewable and the
<glossterm linkend="glossary:Hotspot">hotspot</glossterm> 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 <quote>in</quote> a window if the window contains the pointer
but no inferior contains the pointer.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Coordinate_system">
  <glossterm>Coordinate system</glossterm>
  <indexterm zone="glossary:Coordinate_system" significance="preferred"><primary>Coordinate system</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Cursor">
  <glossterm>Cursor</glossterm>
  <indexterm zone="glossary:Cursor" significance="preferred"><primary>Cursor</primary></indexterm>
  <glossdef>
    <para>
A cursor is the visible shape of the pointer on a screen.
It consists of a <glossterm linkend="glossary:Hotspot">hotspot</glossterm>,
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Depth">
  <glossterm>Depth</glossterm>
  <indexterm zone="glossary:Depth" significance="preferred"><primary>Depth</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Device">
  <glossterm>Device</glossterm>
  <indexterm zone="glossary:Device" significance="preferred"><primary>Device</primary></indexterm>
  <glossdef>
    <para>
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,
<quote>the keyboard</quote> and <quote>the pointer.</quote>
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:DirectColor">
  <glossterm>DirectColor</glossterm>
  <indexterm zone="glossary:DirectColor" significance="preferred"><primary>DirectColor</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>DirectColor</emphasis>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Display">
  <glossterm>Display</glossterm>
  <indexterm zone="glossary:Display" significance="preferred"><primary>Display</primary></indexterm>
  <glossdef>
    <para>
A server, together with its screens and input devices, is called a display.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Drawable">
  <glossterm>Drawable</glossterm>
  <indexterm zone="glossary:Drawable" significance="preferred"><primary>Drawable</primary></indexterm>
  <glossdef>
    <para>
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
<glossterm linkend="glossary:InputOnly_window"><emphasis role='bold'>InputOnly</emphasis></glossterm>
window cannot be used as a source or destination in a graphics operation.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Event">
  <glossterm>Event</glossterm>
  <indexterm zone="glossary:Event" significance="preferred"><primary>Event</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Event_mask">
  <glossterm>Event mask</glossterm>
  <indexterm zone="glossary:Event_mask" significance="preferred"><primary>Event</primary><secondary>mask</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Event_synchronization">
  <glossterm>Event synchronization</glossterm>
  <indexterm zone="glossary:Event_synchronization" significance="preferred"><primary>Event</primary><secondary>synchronization</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Event_propagation">
  <glossterm>Event propagation</glossterm>
  <indexterm zone="glossary:Event_propagation" significance="preferred"><primary>Event</primary><secondary>propagation</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Event_source">
  <glossterm>Event source</glossterm>
  <indexterm zone="glossary:Event_source" significance="preferred"><primary>Event</primary><secondary>source</secondary></indexterm>
  <glossdef>
    <para>
The window the pointer is in is the source of a device-related
event.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Exposure_event">
  <glossterm>Exposure event</glossterm>
  <indexterm zone="glossary:Exposure_event" significance="preferred"><primary>Event</primary><secondary>Exposure</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Extension">
  <glossterm>Extension</glossterm>
  <indexterm zone="glossary:Extension" significance="preferred"><primary>Extension</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Focus_window">
  <glossterm>Focus window</glossterm>
  <indexterm zone="glossary:Focus_window" significance="preferred"><primary>Focus window</primary></indexterm>
  <glossdef>
    <para>
The focus window is another term for the <glossterm linkend="glossary:Input_focus">input focus</glossterm>.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Font">
  <glossterm>Font</glossterm>
  <indexterm zone="glossary:Font" significance="preferred"><primary>Font</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:GC">
  <glossterm>GC, GContext</glossterm>
  <indexterm zone="glossary:GC" significance="preferred"><primary>GC</primary><seealso>Graphics context</seealso></indexterm>
  <indexterm zone="glossary:GC" significance="preferred"><primary>GContext</primary><seealso>Graphics context</seealso></indexterm>
  <glossdef>
    <para>
GC and gcontext are abbreviations for <glossterm linkend="glossary:Graphics_context">graphics context</glossterm>.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Glyph">
  <glossterm>Glyph</glossterm>
  <indexterm zone="glossary:Glyph" significance="preferred"><primary>Glyph</primary></indexterm>
  <glossdef>
    <para>
A glyph is an image, typically of a character, in a font.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Grab">
  <glossterm>Grab</glossterm>
  <indexterm zone="glossary:Grab" significance="preferred"><primary>Grab</primary><seealso>Active grab</seealso><seealso>Passive grab</seealso></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Graphics_context">
  <glossterm>Graphics context</glossterm>
  <indexterm zone="glossary:Graphics_context" significance="preferred"><primary>Graphics context</primary></indexterm>
  <glossdef>
    <para>
Various information for graphics output is stored in a graphics context
such as foreground pixel, background pixel, line width,
<glossterm linkend="glossary:Clipping_region">clipping region</glossterm>,
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Gravity">
  <glossterm>Gravity</glossterm>
  <indexterm zone="glossary:Gravity" significance="preferred"><primary>Gravity</primary></indexterm>
  <glossdef>
    <para>
See <glossterm linkend="glossary:Bit_gravity">bit gravity</glossterm>
and <glossterm linkend="glossary:Window_gravity">window gravity</glossterm>.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:GrayScale">
  <glossterm>GrayScale</glossterm>
  <indexterm zone="glossary:GrayScale" significance="preferred"><primary>GrayScale</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>GrayScale</emphasis>
can be viewed as a degenerate case of
<glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>,
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Hotspot">
  <glossterm>Hotspot</glossterm>
  <indexterm zone="glossary:Hotspot" significance="preferred"><primary>Hotspot</primary></indexterm>
  <glossdef>
    <para>
A cursor has an associated hotspot that defines the point in the
cursor corresponding to the coordinates reported for the pointer.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Identifier">
  <glossterm>Identifier</glossterm>
  <indexterm zone="glossary:Identifier" significance="preferred"><primary>Identifier</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Inferiors">
  <glossterm>Inferiors</glossterm>
  <indexterm zone="glossary:Inferiors" significance="preferred"><primary>Inferiors</primary></indexterm>
  <glossdef>
    <para>
The inferiors of a window are all of the subwindows nested below it:
the children, the children's children, and so on.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Input_focus">
  <glossterm>Input focus</glossterm>
  <indexterm zone="glossary:Input_focus" significance="preferred"><primary>Input focus</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Input_manager">
  <glossterm>Input manager</glossterm>
  <indexterm zone="glossary:Input_manager" significance="preferred"><primary>Input manager</primary></indexterm>
  <glossdef>
    <para>
Control over keyboard input is typically provided by an input manager client.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:InputOnly_window">
  <glossterm>InputOnly window</glossterm>
  <indexterm zone="glossary:InputOnly_window" significance="preferred"><primary>Window</primary><secondary>InputOnly</secondary></indexterm>
  <glossdef>
    <para>
An
<emphasis role='bold'>InputOnly</emphasis>
window is a window that cannot be used for graphics requests.
<emphasis role='bold'>InputOnly</emphasis>
windows are invisible and can be used to control such things
as cursors, input event generation, and grabbing.
<emphasis role='bold'>InputOnly</emphasis>
windows cannot have
<emphasis role='bold'>InputOutput</emphasis>
windows as inferiors.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:InputOutput_window">
  <glossterm>InputOutput window</glossterm>
  <indexterm zone="glossary:InputOutput_window" significance="preferred"><primary>Window</primary><secondary>InputOutput</secondary></indexterm>
  <glossdef>
    <para>
An
<emphasis role='bold'>InputOutput</emphasis>
window is the normal kind of opaque window, used for both input and output.
<emphasis role='bold'>InputOutput</emphasis>
windows can have both
<emphasis role='bold'>InputOutput</emphasis>
and
<emphasis role='bold'>InputOnly</emphasis>
windows as inferiors.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Key_grabbing">
  <glossterm>Key grabbing</glossterm>
  <indexterm zone="glossary:Key_grabbing" significance="preferred"><primary>Key</primary><secondary>grabbing</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Keyboard_grabbing">
  <glossterm>Keyboard grabbing</glossterm>
  <indexterm zone="glossary:Keyboard_grabbing" significance="preferred"><primary>Keyboard</primary><secondary>grabbing</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Keysym">
  <glossterm>Keysym</glossterm>
  <indexterm zone="glossary:Keysym" significance="preferred"><primary>Keysym</primary></indexterm>
  <glossdef>
    <para>
An encoding of a symbol on a keycap on a keyboard.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Mapped">
  <glossterm>Mapped</glossterm>
  <indexterm zone="glossary:Mapped" significance="preferred"><primary>Mapped window</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Modifier_keys">
  <glossterm>Modifier keys</glossterm>
  <indexterm zone="glossary:Modifier_keys" significance="preferred"><primary>Modifier keys</primary></indexterm>
  <indexterm zone="glossary:Modifier_keys"><primary>Key</primary><secondary>modifier</secondary><see>Modifier keys</see></indexterm>
  <glossdef>
    <para>
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called modifier keys.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Monochrome">
  <glossterm>Monochrome</glossterm>
  <indexterm zone="glossary:Monochrome" significance="preferred"><primary>Monochrome</primary></indexterm>
  <glossdef>
    <para>
Monochrome is a special case of
<glossterm linkend="glossary:StaticGray"><emphasis role='bold'>StaticGray</emphasis></glossterm>
in which there are only two colormap entries.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Obscure">
  <glossterm>Obscure</glossterm>
  <indexterm zone="glossary:Obscure" significance="preferred"><primary>Obscure</primary></indexterm>
  <glossdef>
    <para>
A window is obscured if some other window obscures it.
Window A obscures window B if both are viewable
<glossterm linkend="glossary:InputOutput_window"><emphasis role='bold'>InputOutput</emphasis></glossterm>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Occlude">
  <glossterm>Occlude</glossterm>
  <indexterm zone="glossary:Occlude" significance="preferred"><primary>Occlude</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Padding">
  <glossterm>Padding</glossterm>
  <indexterm zone="glossary:Padding" significance="preferred"><primary>Padding</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Parent_window">
  <glossterm>Parent window</glossterm>
  <indexterm zone="glossary:Parent_window" significance="preferred"><primary>Window</primary><secondary>parent</secondary></indexterm>
  <glossdef>
    <para>
If C is a <glossterm linkend="glossary:Children">child</glossterm> of P,
then P is the parent of C.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Passive_grab">
  <glossterm>Passive grab</glossterm>
  <indexterm zone="glossary:Passive_grab" significance="preferred"><primary>Passive grab</primary></indexterm>
  <glossdef>
    <para>
Grabbing a key or button is a passive grab.
The grab activates when the key or button is actually pressed.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Pixel_value">
  <glossterm>Pixel value</glossterm>
  <indexterm zone="glossary:Pixel_value" significance="preferred"><primary>Pixel value</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Pixmap">
  <glossterm>Pixmap</glossterm>
  <indexterm zone="glossary:Pixmap" significance="preferred"><primary>Pixmap</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Plane">
  <glossterm>Plane</glossterm>
  <indexterm zone="glossary:Plane" significance="preferred"><primary>Plane</primary></indexterm>
  <glossdef>
    <para>
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a plane or bit plane.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Plane_mask">
  <glossterm>Plane mask</glossterm>
  <indexterm zone="glossary:Plane_mask" significance="preferred"><primary>Plane</primary><secondary>mask</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Pointer">
  <glossterm>Pointer</glossterm>
  <indexterm zone="glossary:Pointer" significance="preferred"><primary>Pointer</primary></indexterm>
  <glossdef>
    <para>
The pointer is the pointing device attached to the cursor
and tracked on the screens.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Pointer_grabbing">
  <glossterm>Pointer grabbing</glossterm>
  <indexterm zone="glossary:Pointer_grabbing" significance="preferred"><primary>Pointer</primary><secondary>grabbing</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Pointing_device">
  <glossterm>Pointing device</glossterm>
  <indexterm zone="glossary:Pointing_device" significance="preferred"><primary>Pointing device</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Property">
  <glossterm>Property</glossterm>
  <indexterm zone="glossary:Property" significance="preferred"><primary>Property</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Property_list">
  <glossterm>Property list</glossterm>
  <indexterm zone="glossary:Property_list" significance="preferred"><primary>Property list</primary></indexterm>
  <glossdef>
    <para>
The property list of a window is the list of properties that have
been defined for the window.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:PseudoColor">
  <glossterm>PseudoColor</glossterm>
  <indexterm zone="glossary:PseudoColor" significance="preferred"><primary>PseudoColor</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>PseudoColor</emphasis>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Redirecting_control">
  <glossterm>Redirecting control</glossterm>
  <indexterm zone="glossary:Redirecting_control" significance="preferred"><primary>Redirecting control</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Reply">
  <glossterm>Reply</glossterm>
  <indexterm zone="glossary:Reply" significance="preferred"><primary>Reply</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Request">
  <glossterm>Request</glossterm>
  <indexterm zone="glossary:Request" significance="preferred"><primary>Request</primary></indexterm>
  <glossdef>
    <para>
A command to the server is called a request.
It is a single block of data sent over a connection.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Resource">
  <glossterm>Resource</glossterm>
  <indexterm zone="glossary:Resource" significance="preferred"><primary>Resource</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:RGB_values">
  <glossterm>RGB values</glossterm>
  <indexterm zone="glossary:RGB_values" significance="preferred"><primary>RGB values</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Root">
  <glossterm>Root</glossterm>
  <indexterm zone="glossary:Root" significance="preferred"><primary>Root</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Root_window">
  <glossterm>Root window</glossterm>
  <indexterm zone="glossary:Root_window" significance="preferred"><primary>Window</primary><secondary>root</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Save_set">
  <glossterm>Save set</glossterm>
  <indexterm zone="glossary:Save_set" significance="preferred"><primary>Save set</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Scanline">
  <glossterm>Scanline</glossterm>
  <indexterm zone="glossary:Scanline" significance="preferred"><primary>Scanline</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Scanline_order">
  <glossterm>Scanline order</glossterm>
  <indexterm zone="glossary:Scanline_order" significance="preferred"><primary>Scanline order</primary></indexterm>
  <glossdef>
    <para>
An image represented in scanline order contains scanlines ordered by
increasing y coordinate.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Screen">
  <glossterm>Screen</glossterm>
  <indexterm zone="glossary:Screen" significance="preferred"><primary>Screen</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Selection">
  <glossterm>Selection</glossterm>
  <indexterm zone="glossary:Selection" significance="preferred"><primary>Selection</primary></indexterm>
  <glossdef>
    <para>
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 <quote>owner</quote>).
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 <quote>target type</quote>.
This target type can be used to control the transmitted representation of the
contents.
For example,
if the selection is <quote>the last thing the user clicked on</quote>
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 <quote>looks</quote> (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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Server">
  <glossterm>Server</glossterm>
  <indexterm zone="glossary:Server" significance="preferred"><primary>Server</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Server_grabbing">
  <glossterm>Server grabbing</glossterm>
  <indexterm zone="glossary:Server_grabbing" significance="preferred"><primary>Server</primary><secondary>grabbing</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Sibling">
  <glossterm>Sibling</glossterm>
  <indexterm zone="glossary:Sibling" significance="preferred"><primary>Sibling</primary></indexterm>
  <glossdef>
    <para>
Children of the same parent window are known as sibling windows.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Stacking_order">
  <glossterm>Stacking order</glossterm>
  <indexterm zone="glossary:Stacking_order" significance="preferred"><primary>Stacking order</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:StaticColor">
  <glossterm>StaticColor</glossterm>
  <indexterm zone="glossary:StaticColor" significance="preferred"><primary>StaticColor</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>StaticColor</emphasis>
can be viewed as a degenerate case of
<glossterm linkend="glossary:PseudoColor"><emphasis role='bold'>PseudoColor</emphasis></glossterm>
in which the RGB values are predefined and read-only.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:StaticGray">
  <glossterm>StaticGray</glossterm>
  <indexterm zone="glossary:StaticGray" significance="preferred"><primary>StaticGray</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>StaticGray</emphasis>
can be viewed as a degenerate case of
<glossterm linkend="glossary:GrayScale"><emphasis role='bold'>GrayScale</emphasis></glossterm>
in which the gray values are predefined and read-only.
The values are typically linear or near-linear increasing ramps.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Stipple">
  <glossterm>Stipple</glossterm>
  <indexterm zone="glossary:Stipple" significance="preferred"><primary>Stipple</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:String_Equivalence">
  <glossterm>String Equivalence</glossterm>
  <indexterm zone="glossary:String_Equivalence" significance="preferred"><primary>String Equivalence</primary></indexterm>
  <glossdef>
    <para>
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 <quote>A</quote> to <quote>Z</quote>) are
pairwise equivalent to decimal values 97 to 122 inclusive
(characters <quote>a</quote> to <quote>z</quote>), decimal values 192 to 214 inclusive
(characters <quote>A grave</quote> to <quote>O diaeresis</quote>) are pairwise equivalent to decimal
values 224 to 246 inclusive (characters <quote>a grave</quote> to <quote>o diaeresis</quote>),
and decimal values 216 to 222 inclusive (characters <quote>O oblique</quote> to <quote>THORN</quote>)
are pairwise equivalent to decimal values 246 to 254 inclusive
(characters <quote>o oblique</quote> to <quote>thorn</quote>).
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Tile">
  <glossterm>Tile</glossterm>
  <indexterm zone="glossary:Tile" significance="preferred"><primary>Tile</primary></indexterm>
  <glossdef>
    <para>
A pixmap can be replicated in two dimensions to tile a region.
The pixmap itself is also known as a tile.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Timestamp">
  <glossterm>Timestamp</glossterm>
  <indexterm zone="glossary:Timestamp" significance="preferred"><primary>Timestamp</primary></indexterm>
  <indexterm zone="glossary:Timestamp" significance="preferred"><primary>CurrentTime</primary></indexterm>
  <glossdef>
    <para>
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
<emphasis role='bold'>CurrentTime</emphasis>)
is never generated by the server.
This value is reserved for use in requests to represent the current
server time.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:TrueColor">
  <glossterm>TrueColor</glossterm>
  <indexterm zone="glossary:TrueColor" significance="preferred"><primary>TrueColor</primary></indexterm>
  <glossdef>
    <para>
<emphasis role='bold'>TrueColor</emphasis>
can be viewed as a degenerate case of
<glossterm linkend="glossary:DirectColor"><emphasis role='bold'>DirectColor</emphasis></glossterm>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Type">
  <glossterm>Type</glossterm>
  <indexterm zone="glossary:Type" significance="preferred"><primary>Type</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Viewable">
  <glossterm>Viewable</glossterm>
  <indexterm zone="glossary:Viewable" significance="preferred"><primary>Viewable</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Visible">
  <glossterm>Visible</glossterm>
  <indexterm zone="glossary:Visible" significance="preferred"><primary>Visible</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Window_gravity">
  <glossterm>Window gravity</glossterm>
  <indexterm zone="glossary:Window_gravity" significance="preferred"><primary>Window</primary><secondary>gravity</secondary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:Window_manager">
  <glossterm>Window manager</glossterm>
  <indexterm zone="glossary:Window_manager" significance="preferred"><primary>Window</primary><secondary>manager</secondary></indexterm>
  <glossdef>
    <para>
Manipulation of windows on the screen and much of the user interface
(policy) is typically provided by a window manager client.
<!-- .KE -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:XYFormat">
  <glossterm>XYFormat</glossterm>
  <indexterm zone="glossary:XYFormat" significance="preferred"><primary>XYFormat</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
<glossentry id="glossary:ZFormat">
  <glossterm>ZFormat</glossterm>
  <indexterm zone="glossary:ZFormat" significance="preferred"><primary>ZFormat</primary></indexterm>
  <glossdef>
    <para>
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 -->
    </para>
  </glossdef>
</glossentry>
</glossary>