diff --git a/specs/encoding.xml b/specs/encoding.xml index 5ec5b5c..de94956 100644 --- a/specs/encoding.xml +++ b/specs/encoding.xml @@ -72,10 +72,10 @@ For components with a static numeric value the encode-form is: The value is always interpreted as an N-byte unsigned integer. For example, the first two bytes of a -Window +Window error are always zero (indicating an error in general) and three (indicating the -Window +Window error in particular): @@ -90,8 +90,8 @@ For components described in the protocol as: name: -{ Name1 ,..., -NameI } +{ Name1,..., +NameI} @@ -159,7 +159,7 @@ For example: destination: WINDOW or -PointerWindow +PointerWindow or InputFocus diff --git a/specs/glossary.xml b/specs/glossary.xml index 5a89b2d..4bf94b5 100644 --- a/specs/glossary.xml +++ b/specs/glossary.xml @@ -58,7 +58,7 @@ Atoms are used to identify properties, types, and selections. An -InputOutput +InputOutput window can have a background, which is defined as a pixmap. When regions of the window have their contents lost or invalidated, the server will automatically tile those regions with the background. @@ -119,7 +119,7 @@ A bitmap is a pixmap of depth o An -InputOutput +InputOutput window can have a border of equal thickness on all four sides of the window. A pixmap defines the contents of the border, and the server automatically maintains the contents of the border. @@ -333,7 +333,7 @@ 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 -InputOnly +InputOnly window cannot be used as a source or destination in a graphics operation. @@ -523,7 +523,7 @@ and window gravity. GrayScale -GrayScale +GrayScale can be viewed as a degenerate case of PseudoColor, in which the red, green, and blue values in any given colormap entry are equal, @@ -605,12 +605,12 @@ Control over keyboard input is typically provided by an input manager client. An InputOnly window is a window that cannot be used for graphics requests. -InputOnly +InputOnly windows are invisible and can be used to control such things as cursors, input event generation, and grabbing. -InputOnly +InputOnly windows cannot have -InputOutput +InputOutput windows as inferiors. @@ -624,11 +624,11 @@ windows as inferiors. An InputOutput window is the normal kind of opaque window, used for both input and output. -InputOutput +InputOutput windows can have both -InputOutput +InputOutput and -InputOnly +InputOnly windows as inferiors. @@ -709,7 +709,7 @@ in which there are only two colormap entries. A window is obscured if some other window obscures it. Window A obscures window B if both are viewable -InputOutput +InputOutput windows, A is higher in the global stacking order, and the rectangle defined by the outside edges of A intersects the rectangle defined by the outside edges of B. @@ -1124,7 +1124,7 @@ The relationship between sibling windows is known as the stacking order. StaticColor -StaticColor +StaticColor can be viewed as a degenerate case of PseudoColor in which the RGB values are predefined and read-only. @@ -1137,7 +1137,7 @@ in which the RGB values are predefined and read-only. StaticGray -StaticGray +StaticGray can be viewed as a degenerate case of GrayScale in which the gray values are predefined and read-only. @@ -1202,7 +1202,7 @@ 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 -CurrentTime ) +CurrentTime) is never generated by the server. This value is reserved for use in requests to represent the current server time. diff --git a/specs/keysyms.xml b/specs/keysyms.xml index 810fe3c..0b457ae 100644 --- a/specs/keysyms.xml +++ b/specs/keysyms.xml @@ -40,9 +40,9 @@ There are six categories of KEYSYM values. Special KEYSYMs There are two special values: -NoSymbol +NoSymbol and -VoidSymbol . +VoidSymbol. They are used to indicate the absence of symbols (see Section 5, Keyboards). diff --git a/specs/sect1-9.xml b/specs/sect1-9.xml index 0d3cf92..c17c93f 100644 --- a/specs/sect1-9.xml +++ b/specs/sect1-9.xml @@ -155,12 +155,12 @@ Events are 32 bytes long. Unused bytes within an event are not guaranteed to be zero. Every event contains an 8-bit type code. The most significant bit in this code is set if the event was generated from a -SendEvent +SendEvent request. Event codes 64 through 127 are reserved for extensions, although the core protocol does not define a mechanism for selecting interest in such events. Every core event (with the exception of -KeymapNotify ) +KeymapNotify) also contains the least significant 16 bits of the sequence number of the last request issued by the client that was (or is currently being) processed by the server. @@ -190,7 +190,7 @@ The syntax [...] encloses a set of structure components. In general, TYPEs are in uppercase and -AlternativeValues +AlternativeValues are capitalized. @@ -298,7 +298,7 @@ each such argument is assigned a unique bit position. The representation of the BITMASK will typically contain more bits than there are defined arguments. The unused bits in the value-mask must be zero (or the server generates a -Value +Value error). The value-list contains one value for each bit set to 1 in the mask, from least significant to most significant bit in the mask. @@ -604,7 +604,7 @@ byte-swap CHAR2B quantities. The length, format, and interpretation of a HOST address are specific to the family (see -ChangeHosts +ChangeHosts request). @@ -744,7 +744,7 @@ server. MatchError CodesMatch An -InputOnly +InputOnly window is used as a DRAWABLE. In a graphics request, the GCONTEXT argument does not have the same root and depth as the destination DRAWABLE argument. @@ -847,14 +847,14 @@ If the list (ignoring trailing NoSymbol entries) is a pair of KEYSYMs if it were the list "K1 K2 K1 K2". If the list (ignoring trailing -NoSymbol +NoSymbol entries) is a triple of KEYSYMs "K1 K2 K3", then the list is treated as if it were the list " K1 K2 K3 NoSymbol". When an explicit "void" element is desired in the list, the value -VoidSymbol +VoidSymbol can be used. @@ -864,7 +864,7 @@ Group 1 contains the first and second KEYSYMs, Group 2 contains the third and fourth KEYSYMs. Within each group, if the second element of the group is -NoSymbol , +NoSymbol, then the group should be treated as if the second element were the same as the first element, except when the first element is an alphabetic KEYSYM "K" for which both lowercase @@ -877,15 +877,15 @@ of "K". The standard rules for obtaining a KEYSYM from a -KeyPress +KeyPress event make use of only the Group 1 and Group 2 KEYSYMs; no interpretation of other KEYSYMs in the list is defined. The modifier state determines which group to use. Switching between groups is controlled by the KEYSYM named MODE SWITCH, by attaching that KEYSYM to some KEYCODE and attaching that KEYCODE to any one of the modifiers -Mod1 +Mod1 through -Mod5 . +Mod5. This modifier is called the "group modifier". For any KEYCODE, Group 1 is used when the group modifier is off, and Group 2 is used when the group modifier is on. @@ -893,18 +893,18 @@ group modifier is off, and Group 2 is used when the group modifier is on. The -Lock +Lock modifier is interpreted as CapsLock when the KEYSYM named CAPS LOCK is attached to some KEYCODE and that KEYCODE is attached to the -Lock +Lock modifier. The -Lock +Lock modifier is interpreted as ShiftLock when the KEYSYM named SHIFT LOCK is attached to some KEYCODE and that KEYCODE is attached to the -Lock +Lock modifier. If the -Lock +Lock modifier could be interpreted as both CapsLock and ShiftLock, the CapsLock interpretation is used. @@ -914,9 +914,9 @@ CapsLock and ShiftLock, the CapsLock interpretation is used. The operation of "keypad" keys is controlled by the KEYSYM named NUM LOCK, by attaching that KEYSYM to some KEYCODE and attaching that KEYCODE to any one of the modifiers -Mod1 +Mod1 through -Mod5 . +Mod5. This modifier is called the "numlock modifier". The standard KEYSYMs with the prefix KEYPAD in their name are called "keypad" KEYSYMs; these are KEYSYMS with numeric value in @@ -935,9 +935,9 @@ rule that is satisfied from the following list: The numlock modifier is on and the second KEYSYM is a keypad KEYSYM. In this case, if the -Shift +Shift modifier is on, or if the -Lock +Lock modifier is on and is interpreted as ShiftLock, then the first KEYSYM is used; otherwise, the second KEYSYM is used. @@ -946,9 +946,9 @@ second KEYSYM is used. The -Shift +Shift and -Lock +Lock modifiers are both off. In this case, the first KEYSYM is used. @@ -956,9 +956,9 @@ KEYSYM is used. The -Shift +Shift modifier is off, and the -Lock +Lock modifier is on and is interpreted as CapsLock. In this case, the first KEYSYM is used, but if that KEYSYM is lowercase alphabetic, then the corresponding uppercase @@ -968,9 +968,9 @@ KEYSYM is used instead. The -Shift +Shift modifier is on, and the -Lock +Lock modifier is on and is interpreted as CapsLock. In this case, the second KEYSYM is used, but if that KEYSYM is lowercase alphabetic, then the corresponding uppercase KEYSYM is used @@ -980,9 +980,9 @@ instead. The -Shift +Shift modifier is on, or the -Lock +Lock modifier is on and is interpreted as ShiftLock, or both. In this case, the second KEYSYM is used. @@ -1015,7 +1015,7 @@ Buttons are always numbered starting with one. Predefined atoms are not strictly necessary and may not be useful in all environments, but they will eliminate many -InternAtom +InternAtom requests in most applications. Note that they are predefined only in the sense of having numeric values, not in the sense of having required semantics. @@ -1299,7 +1299,7 @@ or The client receives the following additional data if the returned success value is -Success , +Success, and the connection is successfully established: @@ -1580,10 +1580,10 @@ No geometry is defined among screens. The server may retain the recent history of pointer motion and do so to a finer granularity than is reported by -MotionNotify +MotionNotify events. The -GetMotionEvents +GetMotionEvents request makes such history available. The motion-buffer-size gives the approximate maximum number of elements in the history buffer. @@ -1595,7 +1595,7 @@ accepted by the server, in 4-byte units. That is, length is the maximum value that can appear in the length field of a request. Requests larger than this maximum generate a -Length +Length error, and the server will read and simply discard the entire request. Maximum-request-length will always be at least 4096 @@ -1627,7 +1627,7 @@ A pixmap depth of one is always supported and listed, but windows of depth one might not be supported. A depth of zero is never listed, but zero-depth -InputOnly +InputOnly windows are always supported. @@ -1637,7 +1637,7 @@ root window. Width-in-pixels and height-in-pixels specify the size of the root window (which cannot be changed). The class of the root window is always -InputOutput . +InputOutput. Width-in-millimeters and height-in-millimeters can be used to determine the physical size and the aspect ratio. @@ -1668,7 +1668,7 @@ unspecified two-color pattern using black-pixel and white-pixel. Min-installed-maps specifies the number of maps that can be guaranteed to be installed simultaneously (with -InstallColormap ), +InstallColormap), regardless of the number of entries allocated in each map. Max-installed-maps specifies the maximum number of maps that might possibly be installed simultaneously, depending on their allocations. @@ -1683,17 +1683,17 @@ Backing-stores indicates when the server supports backing stores for this screen, although it may be storage limited in the number of windows it can support at once. If save-unders is -True , +True, the server can support the save-under mode in -CreateWindow +CreateWindow and -ChangeWindowAttributes , +ChangeWindowAttributes, although again it may be storage limited. The current-input-events is what -GetWindowAttributes +GetWindowAttributes would return for the all-event-masks for the root window. @@ -1712,45 +1712,45 @@ more than one screen. For -PseudoColor , +PseudoColor, a pixel value indexes a colormap to produce independent RGB values; the RGB values can be changed dynamically. -GrayScale +GrayScale is treated in the same way as -PseudoColor +PseudoColor except which primary drives the screen is undefined; thus, the client should always store the same value for red, green, and blue in colormaps. For -DirectColor , +DirectColor, a pixel value is decomposed into separate RGB subfields, and each subfield separately indexes the colormap for the corresponding value. The RGB values can be changed dynamically. -TrueColor +TrueColor is treated in the same way as -DirectColor +DirectColor except the colormap has predefined read-only RGB values. These values are server-dependent but provide linear or near-linear increasing ramps in each primary. -StaticColor +StaticColor is treated in the same way as -PseudoColor +PseudoColor except the colormap has predefined read-only RGB values, which are server-dependent. -StaticGray +StaticGray is treated in the same way as -StaticColor +StaticColor except the red, green, and blue values are equal for any single pixel value, resulting in shades of gray. -StaticGray +StaticGray with a two-entry colormap can be thought of as monochrome. The red-mask, green-mask, and blue-mask are only defined for -DirectColor +DirectColor and -TrueColor . +TrueColor. Each has one contiguous set of bits set to 1 with no intersections. Usually each mask has the same number of bits set to 1. @@ -1779,9 +1779,9 @@ Colormap entries are indexed from 0. The colormap-entries defines the number of available colormap entries in a newly created colormap. For -DirectColor +DirectColor and -TrueColor , +TrueColor, this will usually be 2 to the power of the maximum number of bits set to 1 in red-mask, green-mask, and blue-mask. @@ -1809,9 +1809,9 @@ red-mask, green-mask, and blue-mask. class: -{ InputOutput , -InputOnly , -CopyFromParent } +{ InputOutput, +InputOnly, +CopyFromParent} @@ -1850,13 +1850,13 @@ red-mask, green-mask, and blue-mask. Errors: -Alloc , -Colormap , -Cursor , -IDChoice , -Match , -Pixmap , -Value , +Alloc, +Colormap, +Cursor, +IDChoice, +Match, +Pixmap, +Value, Window @@ -1871,51 +1871,51 @@ This request creates an unmapped window and assigns the identifier wid to it. A class of -CopyFromParent +CopyFromParent means the class is taken from the parent. A depth of zero for class -InputOutput +InputOutput or -CopyFromParent +CopyFromParent means the depth is taken from the parent. A visual of -CopyFromParent +CopyFromParent means the visual type is taken from the parent. For class -InputOutput , +InputOutput, the visual type and depth must be a combination supported for the screen (or a -Match +Match error results). The depth need not be the same as the parent, but the parent must not be of class -InputOnly +InputOnly (or a -Match +Match error results). For class -InputOnly , +InputOnly, the depth must be zero (or a -Match +Match error results), and the visual must be one supported for the screen (or a -Match +Match error results). However, the parent can have any depth and class. The server essentially acts as if -InputOnly +InputOnly windows do not exist for the purposes of graphics requests, exposure processing, and -VisibilityNotify +VisibilityNotify events. An -InputOnly +InputOnly window cannot be used as a drawable (as a source or destination for graphics requests). -InputOnly +InputOnly and -InputOutput +InputOutput windows act identically in other respects-properties, grabs, input control, and so on. @@ -1936,12 +1936,12 @@ and specify the position of the upper-left outer corner of the window (not the origin). The width and height specify the inside size (not including the border) and must be nonzero (or a -Value +Value error results). The border-width for an -InputOnly +InputOnly window must be zero (or a -Match +Match error results). @@ -1967,7 +1967,7 @@ The possible values are: background-pixmap PIXMAP or -None +None or ParentRelative @@ -2171,9 +2171,9 @@ cursor It is a -Match +Match error to specify any other attributes for -InputOnly +InputOnly windows. @@ -2181,22 +2181,22 @@ If background-pixmap is given, it overrides the default background-pixmap. The background pixmap and the window must have the same root and the same depth (or a -Match +Match error results). Any size pixmap can be used, although some sizes may be faster than others. If background -None +None is specified, the window has no defined background. If background -ParentRelative +ParentRelative is specified, the parent's background is used, but the window must have the same depth as the parent (or a -Match +Match error results). If the parent has background -None , +None, then the window will also have background -None . +None. A copy of the parent's background is not made. The parent's background is reexamined each time the window background is required. @@ -2207,7 +2207,7 @@ background. Range checking is not performed on the background-pixel value; it is simply truncated to the appropriate number of bits. For a -ParentRelative +ParentRelative background, the background tile origin always aligns with the parent's background tile origin. @@ -2218,15 +2218,15 @@ When no valid contents are available for regions of a window and the regions are either visible or the server is maintaining backing store, the server automatically tiles the regions with the window's background unless the window has a background of -None . +None. If the background is -None , +None, the previous screen contents from other windows of the same depth as the window are simply left in place if the contents come from the parent of the window or an inferior of the parent; otherwise, the initial contents of the exposed regions are undefined. Exposure events are then generated for the regions, even if the background is -None . +None. The border tile origin is always the same as the background tile origin. @@ -2234,16 +2234,16 @@ If border-pixmap is given, it overrides the default border-pixmap. The border pixmap and the window must have the same root and the same depth (or a -Match +Match error results). Any size pixmap can be used, although some sizes may be faster than others. If -CopyFromParent +CopyFromParent is given, the parent's border pixmap is copied (subsequent changes to the parent's border attribute do not affect the child), but the window must have the same depth as the parent (or a -Match +Match error results). The pixmap might be copied by sharing the same pixmap object between the child and parent or by making a complete copy of the pixmap contents. @@ -2261,22 +2261,22 @@ so that the border is never affected. The bit-gravity defines which region of the window should be retained if the window is resized, and win-gravity defines how the window should be repositioned if the parent is resized (see -ConfigureWindow +ConfigureWindow request). A backing-store of -WhenMapped +WhenMapped advises the server that maintaining contents of obscured regions when the window is mapped would be beneficial. A backing-store of -Always +Always advises the server that maintaining contents even when the window is unmapped would be beneficial. In this case, the server may generate an exposure event when the window is created. A value of -NotUseful +NotUseful advises the server that maintaining contents is unnecessary, although a server may still choose to maintain contents while the window is mapped. @@ -2290,7 +2290,7 @@ but the server may stop maintaining contents at any time. If save-under is -True , +True, the server is advised that when this window is mapped, saving the contents of windows it obscures would be beneficial. @@ -2331,26 +2331,26 @@ The colormap specifies the colormap that best reflects the true colors of the window. Servers capable of supporting multiple hardware colormaps may use this information, and window managers may use it for -InstallColormap +InstallColormap requests. The colormap must have the same visual type and root as the window (or a Match error results). If -CopyFromParent +CopyFromParent is specified, the parent's colormap is copied (subsequent changes to the parent's colormap attribute do not affect the child). However, the window must have the same visual type as the parent (or a -Match +Match error results), and the parent must not have a colormap of -None +None (or a -Match +Match error results). For an explanation of -None , -see FreeColormap +None, +see FreeColormap request. The colormap is copied by sharing the colormap object between the child and the parent, @@ -2360,7 +2360,7 @@ not by making a complete copy of the colormap contents. If a cursor is specified, it will be used whenever the pointer is in the window. If -None +None is specified, the parent's cursor will be used when the pointer is in the window, and any change in the parent's cursor will cause an immediate change @@ -2368,7 +2368,7 @@ in the displayed cursor. This request generates a -CreateNotify +CreateNotify event. @@ -2410,12 +2410,12 @@ The server might or might not make a copy of the pixmap. Errors: -Access , -Colormap , -Cursor , -Match , -Pixmap , -Value , +Access, +Colormap, +Cursor, +Match, +Pixmap, +Value, Window @@ -2428,7 +2428,7 @@ Errors: The value-mask and value-list specify which attributes are to be changed. The values and restrictions are the same as for -CreateWindow . +CreateWindow. Setting a new background, whether by background-pixmap or @@ -2441,12 +2441,12 @@ Changing the background does not cause the window contents to be changed. Setting the border or changing the background such that the border tile origin changes causes the border to be repainted. Changing the background of a root window to -None +None or -ParentRelative +ParentRelative restores the default background pixmap. Changing the border of a root window to -CopyFromParent +CopyFromParent restores the default border pixmap. @@ -2455,9 +2455,9 @@ window. Changing the backing-store of an obscured window to -WhenMapped +WhenMapped or -Always +Always or changing the backing-planes, backing-pixel, or save-under of a mapped window may have no immediate effect. @@ -2467,13 +2467,13 @@ their event-masks are disjoint. When an event is generated, it will be reported to all interested clients. However, only one client at a time can select for -SubstructureRedirect , +SubstructureRedirect, only one client at a time can select for -ResizeRedirect , +ResizeRedirect, and only one client at a time can select for -ButtonPress . +ButtonPress. An attempt to violate these restrictions results in an -Access +Access error. @@ -2483,16 +2483,16 @@ client. Changing the colormap of a window (by defining a new map, not by changing the contents of the existing map) generates a -ColormapNotify +ColormapNotify event. Changing the colormap of a visible window might have no immediate effect on the screen (see -InstallColormap +InstallColormap request). Changing the cursor of a root window to -None +None restores the default cursor. @@ -2530,8 +2530,8 @@ visual: VISUALID class: -{ InputOutput , -InputOnly } +{ InputOutput, +InputOnly} @@ -2547,9 +2547,9 @@ win-gravity: WINGRAVITY backing-store: -{ NotUseful , -WhenMapped , -Always } +{ NotUseful, +WhenMapped, +Always} @@ -2581,9 +2581,9 @@ map-is-installed: BOOL map-state: -{ Unmapped , -Unviewable , -Viewable } +{ Unmapped, +Unviewable, +Viewable} @@ -2618,7 +2618,7 @@ Errors: This request returns the current attributes of the window. A window is -Unviewable +Unviewable if it is mapped but some ancestor is unmapped. All-event-masks is the inclusive-OR of all event masks selected on the window by clients. @@ -2656,15 +2656,15 @@ Errors: If the argument window is mapped, an -UnmapWindow +UnmapWindow request is performed automatically. The window and all inferiors are then destroyed, and a -DestroyNotify +DestroyNotify event is generated for each window. The ordering of the -DestroyNotify +DestroyNotify events is such that for any given window, -DestroyNotify +DestroyNotify is generated on all inferiors of the window before being generated on the window itself. The ordering among siblings and across subhierarchies is not otherwise @@ -2708,7 +2708,7 @@ Errors: This request performs a -DestroyWindow +DestroyWindow request on all children of the window, in bottom-to-top stacking order. @@ -2729,8 +2729,8 @@ request on all children of the window, in bottom-to-top stacking order. mode: -{ Insert , -Delete } +{ Insert, +Delete} @@ -2738,8 +2738,8 @@ request on all children of the window, in bottom-to-top stacking order. Errors: -Match , -Value , +Match, +Value, Window @@ -2753,7 +2753,7 @@ Errors: This request adds or removes the specified window from the client's save-set. The window must have been created by some other client (or a -Match +Match error results). For further information about the use of the save-set, see section 10. @@ -2787,7 +2787,7 @@ the server automatically removes them from the save-set. Errors: -Match , +Match, Window @@ -2800,7 +2800,7 @@ Errors: If the window is mapped, an -UnmapWindow +UnmapWindow request is performed automatically first. The window is then removed from its current position in the hierarchy and is inserted as a child of the specified parent. @@ -2810,14 +2810,14 @@ window. The window is placed on top in the stacking order with respect to siblings. A -ReparentNotify +ReparentNotify event is then generated. The override-redirect attribute of the window is passed on in this event; a value of -True +True indicates that a window manager should not tamper with this window. Finally, if the window was originally mapped, a -MapWindow +MapWindow request is performed automatically. @@ -2827,7 +2827,7 @@ initial unmap that are immediately obscured by the final map. A -Match +Match error is generated if: The new parent is not on the same screen as the old parent. @@ -2835,11 +2835,11 @@ The new parent is not on the same screen as the old parent. The new parent is the window itself or an inferior of the window. The new parent is -InputOnly , +InputOnly, and the window is not. The window has a -ParentRelative +ParentRelative background, and the new parent is not the same depth as the window. @@ -2876,15 +2876,15 @@ If the window is already mapped, this request has no effect. If the override-redirect attribute of the window is -False +False and some other client has selected -SubstructureRedirect +SubstructureRedirect on the parent, then a -MapRequest +MapRequest event is generated, but the window remains unmapped. Otherwise, the window is mapped, and a -MapNotify +MapNotify event is generated. @@ -2930,7 +2930,7 @@ Errors: This request performs a -MapWindow +MapWindow request on all unmapped children of the window, in top-to-bottom stacking order. @@ -2966,7 +2966,7 @@ Errors: If the window is already unmapped, this request has no effect. Otherwise, the window is unmapped, and an -UnmapNotify +UnmapNotify event is generated. Normal exposure processing on formerly obscured windows is performed. @@ -3001,7 +3001,7 @@ Errors: This request performs an -UnmapWindow +UnmapWindow request on all mapped children of the window, in bottom-to-top stacking order. @@ -3035,8 +3035,8 @@ in bottom-to-top stacking order. Errors: -Match , -Value , +Match, +Value, Window @@ -3106,48 +3106,48 @@ The x and y coordinates are relative to the parent's origin and specify the position of the upper-left outer corner of the window. The width and height specify the inside size, not including the border, and must be nonzero (or a -Value +Value error results). Those values not specified are taken from the existing geometry of the window. Note that changing just the border-width leaves the outer-left corner of the window in a fixed position but moves the absolute position of the window's origin. It is a -Match +Match error to attempt to make the border-width of an -InputOnly +InputOnly window nonzero. If the override-redirect attribute of the window is -False +False and some other client has selected -SubstructureRedirect +SubstructureRedirect on the parent, a -ConfigureRequest +ConfigureRequest event is generated, and no further processing is performed. Otherwise, the following is performed: If some other client has selected -ResizeRedirect +ResizeRedirect on the window and the inside width or height of the window is being changed, a -ResizeRequest +ResizeRequest event is generated, and the current inside width and height are used instead. Note that the override-redirect attribute of the window has no effect on -ResizeRedirect +ResizeRedirect and that -SubstructureRedirect +SubstructureRedirect on the parent has precedence over -ResizeRedirect +ResizeRedirect on the window. The geometry of the window is changed as specified, the window is restacked among siblings, and a -ConfigureNotify +ConfigureNotify event is generated if the state of the window actually changes. If the inside width or height of the window has actually changed, then children of the window are affected, @@ -3247,16 +3247,16 @@ When a window with one of these win-gravities has its parent window resized, the corresponding pair defines the change in position of the window within the parent. This repositioning generates a -GravityNotify +GravityNotify event. -GravityNotify +GravityNotify events are generated after the -ConfigureNotify +ConfigureNotify event is generated. A gravity of -Static +Static indicates that the contents or origin should not move relative to the origin of the root window. If the change in size of the window is coupled with a change @@ -3265,13 +3265,13 @@ then for bit-gravity the change in position of each pixel is [-X, -Y] and for win-gravity the change in position of a child when its parent is so resized is [-X, -Y]. Note that -Static +Static gravity still only takes effect when the width or height of the window is changed, not when the window is simply moved. A bit-gravity of -Forget +Forget indicates that the window contents are always discarded after a size change, even if backing-store or save-under has been requested. The window is tiled with its background (except, if no background is defined, @@ -3282,21 +3282,21 @@ and zero or more exposure events are generated. The contents and borders of inferiors are not affected by their parent's bit-gravity. A server is permitted to ignore the specified bit-gravity and use -Forget +Forget instead. A win-gravity of -Unmap +Unmap is like -NorthWest , +NorthWest, but the child is also unmapped when the parent is resized, and an -UnmapNotify +UnmapNotify event is generated. -UnmapNotify +UnmapNotify events are generated after the -ConfigureNotify +ConfigureNotify event is generated. @@ -3419,7 +3419,7 @@ then the window is placed at the bottom of the stack. It is a -Match +Match error if a sibling is specified without a stack-mode or if the window is not actually a sibling. @@ -3428,7 +3428,7 @@ Note that the computations for BottomIf, TopIf, and -Opposite +Opposite are performed with respect to the window's final geometry (as controlled by the other arguments to the request), not to its initial geometry. @@ -3453,8 +3453,8 @@ Attempts to configure a root window have no effect. direction: -{ RaiseLowest , -LowerHighest } +{ RaiseLowest, +LowerHighest} @@ -3462,7 +3462,7 @@ Attempts to configure a root window have no effect. Errors: -Value , +Value, Window @@ -3474,23 +3474,23 @@ Errors: If some other client has selected -SubstructureRedirect +SubstructureRedirect on the window, then a -CirculateRequest +CirculateRequest event is generated, and no further processing is performed. Otherwise, the following is performed, and then a -CirculateNotify +CirculateNotify event is generated if the window is actually restacked. For -RaiseLowest , -CirculateWindow +RaiseLowest, +CirculateWindow raises the lowest mapped child (if any) that is occluded by another child to the top of the stack. For -LowerHighest , -CirculateWindow +LowerHighest, +CirculateWindow lowers the highest mapped child (if any) that occludes another child to the bottom of the stack. Exposure processing is performed on formerly obscured windows. @@ -3562,7 +3562,7 @@ and the width and height specify the inside size, not including the border. It is legal to pass an -InputOnly +InputOnly window as a drawable to this request. @@ -3659,7 +3659,7 @@ atom: ATOM or Errors: -Alloc , +Alloc, Value @@ -3672,7 +3672,7 @@ Errors: This request returns the atom for the given name. If only-if-exists is -False , +False, then the atom is created if it does not exist. The string should use the ISO Latin-1 encoding. Uppercase and lowercase matter. @@ -3753,9 +3753,9 @@ This request returns the name for the given atom. mode: -{ Replace , -Prepend , -Append } +{ Replace, +Prepend, +Append} @@ -3768,10 +3768,10 @@ This request returns the name for the given atom. Errors: -Alloc , -Atom , -Match , -Value , +Alloc, +Atom, +Match, +Value, Window @@ -3790,27 +3790,27 @@ as necessary. If the mode is -Replace , +Replace, the previous property value is discarded. If the mode is -Prepend +Prepend or -Append , +Append, then the type and format must match the existing property value (or a -Match +Match error results). If the property is undefined, it is treated as defined with the correct type and format with zero-length data. For -Prepend , +Prepend, the data is tacked on to the beginning of the existing data, and for -Append , +Append, it is tacked on to the end of the existing data. This request generates a -PropertyNotify +PropertyNotify event on the window. @@ -3846,7 +3846,7 @@ The maximum size of a property is server-dependent and may vary dynamically. Errors: -Atom , +Atom, Window @@ -3859,7 +3859,7 @@ Errors: This request deletes the property from the specified window if the property exists and generates a -PropertyNotify +PropertyNotify event on the window unless the property does not exist. @@ -3931,8 +3931,8 @@ value: LISTofINT8 or LISTofINT16 or LISTofINT32 Errors: -Atom , -Value , +Atom, +Value, Window @@ -3945,7 +3945,7 @@ Errors: If the specified property does not exist for the specified window, then the return type is -None , +None, the format and bytes-after are zero, and the value is empty. The delete argument is ignored in this case. @@ -3957,7 +3957,7 @@ the bytes-after is the length of the property in bytes and the value is empty. The delete argument is ignored in this case. If the specified property exists and either -AnyPropertyType +AnyPropertyType is specified or the specified type matches the actual type of the property, then the return type is the actual type of the property, the format is the actual format of the property (never zero), @@ -3975,17 +3975,17 @@ A = N - (I + L) The returned value starts at byte index I in the property (indexing from 0), and its length in bytes is L. However, it is a -Value +Value error if long-offset is given such that L is negative. The value of bytes-after is A, giving the number of trailing unread bytes in the stored property. If delete is -True +True and the bytes-after is zero, the property is also deleted from the window, and a -PropertyNotify +PropertyNotify event is generated on the window. @@ -4018,8 +4018,8 @@ event is generated on the window. Errors: -Atom , -Match , +Atom, +Match, Window @@ -4040,19 +4040,19 @@ of property names (right for positive delta, left for negative delta). If delta mod N is nonzero, a -PropertyNotify +PropertyNotify event is generated for each property in the order listed. If an atom occurs more than once in the list or no property with that name is defined for the window, a -Match +Match error is generated. If an -Atom +Atom or -Match +Match error is generated, no properties are changed. @@ -4131,7 +4131,7 @@ This request returns the atoms of properties currently defined on the window. Errors: -Atom , +Atom, Window @@ -4149,21 +4149,21 @@ than the current last-change time of the specified selection or is later than the current server time. Otherwise, the last-change time is set to the specified time with -CurrentTime +CurrentTime replaced by the current server time. If the owner window is specified as -None , +None, then the owner of the selection becomes -None +None (that is, no owner). Otherwise, the owner of the selection becomes the client executing the request. If the new owner (whether a client or -None ) +None) is not the same as the current owner and the current owner is not -None , +None, then the current owner is sent a -SelectionClear +SelectionClear event. @@ -4171,17 +4171,17 @@ If the client that is the owner of a selection is later terminated (that is, its connection is closed) or if the owner window it has specified in the request is later destroyed, then the owner of the selection automatically reverts to -None , +None, but the last-change time is not affected. The selection atom is uninterpreted by the server. The owner window is returned by the -GetSelectionOwner +GetSelectionOwner request and is reported in -SelectionRequest +SelectionRequest and -SelectionClear +SelectionClear events. @@ -4233,7 +4233,7 @@ Errors: This request returns the current owner window of the specified selection, if any. If -None +None is returned, then there is no owner for the selection. @@ -4273,7 +4273,7 @@ is returned, then there is no owner for the selection. Errors: -Atom , +Atom, Window @@ -4286,13 +4286,13 @@ Errors: If the specified selection has an owner, the server sends a -SelectionRequest +SelectionRequest event to that owner. If no owner for the specified selection exists, the server generates a -SelectionNotify +SelectionNotify event to the requestor with property -None . +None. The arguments are passed on unchanged in either of the events. @@ -4308,7 +4308,7 @@ The arguments are passed on unchanged in either of the events. destination: WINDOW or -PointerWindow +PointerWindow or InputFocus @@ -4333,7 +4333,7 @@ or Errors: -Value , +Value, Window @@ -4345,11 +4345,11 @@ Errors: If -PointerWindow +PointerWindow is specified, destination is replaced with the window that the pointer is in. If -InputFocus +InputFocus is specified and the focus window contains the pointer, destination is replaced with the window that the pointer is in. Otherwise, destination is replaced with the focus window. @@ -4361,13 +4361,13 @@ If that client no longer exists, no event is sent. If propagate is -False , +False, then the event is sent to every client selecting on destination any of the event types in event-mask. If propagate is -True +True and no clients have selected on destination any of the event types in event-mask, then destination is replaced with the @@ -4376,7 +4376,7 @@ type in event-mask and no intervening window has that type in its do-not-propagate-mask. If no such window exists or if the window is an ancestor of the focus window and -InputFocus +InputFocus was originally specified as the destination, then the event is not sent to any clients. Otherwise, the event is reported to every client selecting on the final @@ -4385,7 +4385,7 @@ destination any of the types specified in event-mask. The event code must be one of the core events or one of the events defined by an extension (or a -Value +Value error results) so that the server can correctly byte-swap the contents as necessary. The contents of the event are otherwise unaltered and unchecked @@ -4423,8 +4423,8 @@ Active grabs are ignored for this request. pointer-mode, keyboard-mode: -{ Synchronous , -Asynchronous } +{ Synchronous, +Asynchronous} @@ -4455,11 +4455,11 @@ Active grabs are ignored for this request. status: -{ Success , -AlreadyGrabbed , -Frozen , -InvalidTime , -NotViewable } +{ Success, +AlreadyGrabbed, +Frozen, +InvalidTime, +NotViewable} @@ -4467,8 +4467,8 @@ status: Errors: -Cursor , -Value , +Cursor, +Value, Window @@ -4485,11 +4485,11 @@ The request overrides any active pointer grab by this client. If owner-events is -False , +False, all generated pointer events are reported with respect to grab-window and are only reported if selected by event-mask. If owner-events is -True +True and a generated pointer event would normally be reported to this client, it is reported normally. Otherwise, the event is reported with respect to the grab-window and is @@ -4499,30 +4499,30 @@ unreported events are simply discarded. If pointer-mode is -Asynchronous , +Asynchronous, pointer event processing continues normally. If the pointer is currently frozen by this client, then processing of pointer events is resumed. If pointer-mode is -Synchronous , +Synchronous, the state of the pointer (as seen by means of the protocol) appears to freeze, and no further pointer events are generated by the server until the grabbing client issues a releasing -AllowEvents +AllowEvents request or until the pointer grab is released. Actual pointer changes are not lost while the pointer is frozen. They are simply queued for later processing. If keyboard-mode is -Asynchronous , +Asynchronous, keyboard event processing is unaffected by activation of the grab. If keyboard-mode is -Synchronous , +Synchronous, the state of the keyboard (as seen by means of the protocol) appears to freeze, and no further keyboard events are generated by the server until the grabbing client issues a releasing -AllowEvents +AllowEvents request or until the pointer grab is released. Actual keyboard changes are not lost while the keyboard is frozen. They are simply queued for later processing. @@ -4548,29 +4548,29 @@ keep it contained in the window. This request generates -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events. The request fails with status -AlreadyGrabbed +AlreadyGrabbed if the pointer is actively grabbed by some other client. The request fails with status -Frozen +Frozen if the pointer is frozen by an active grab of another client. The request fails with status -NotViewable +NotViewable if grab-window or confine-to window is not viewable or if the confine-to window lies completely outside the boundaries of the root window. The request fails with status -InvalidTime +InvalidTime if the specified time is earlier than the last-pointer-grab time or later than the current server time. Otherwise, the last-pointer-grab time is set to the specified time, with -CurrentTime +CurrentTime replaced by the current server time. @@ -4598,23 +4598,23 @@ replaced by the current server time. This request releases the pointer if this client has it actively grabbed (from either -GrabPointer +GrabPointer or -GrabButton +GrabButton or from a normal button press) and releases any queued events. The request has no effect if the specified time is earlier than the last-pointer-grab time or is later than the current server time. This request generates -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events. An -UngrabPointer +UngrabPointer request is performed automatically if the event window or confine-to window for an active pointer grab becomes not viewable or if window reconfiguration causes the confine-to window to lie @@ -4660,8 +4660,8 @@ completely outside the boundaries of the root window. pointer-mode, keyboard-mode: -{ Synchronous , -Asynchronous } +{ Synchronous, +Asynchronous} @@ -4681,9 +4681,9 @@ completely outside the boundaries of the root window. Errors: -Access , -Cursor , -Value , +Access, +Cursor, +Value, Window @@ -4697,12 +4697,12 @@ Errors: This request establishes a passive grab. In the future, the pointer is actively grabbed as described in -GrabPointer , +GrabPointer, the last-pointer-grab time is set to the time at which the button was pressed (as transmitted in the -ButtonPress +ButtonPress event), and the -ButtonPress +ButtonPress event is reported if all of the following conditions are true: The pointer is not grabbed and the specified button is logically pressed @@ -4718,7 +4718,7 @@ on any ancestor of grab-window. The interpretation of the remaining arguments is the same as for -GrabPointer . +GrabPointer. The active grab is terminated automatically when the logical state of the pointer has all buttons released, independent of the logical state of modifier keys. @@ -4729,29 +4729,29 @@ may lag the physical state if device event processing is frozen. This request overrides all previous passive grabs by the same client on the same button/key combinations on the same window. A modifier of -AnyModifier +AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no modifiers). It is not required that all specified modifiers have currently assigned keycodes. A button of -AnyButton +AnyButton is equivalent to issuing the request for all possible buttons. Otherwise, it is not required that the button specified currently be assigned to a physical button. An -Access +Access error is generated if some other client has already issued a -GrabButton +GrabButton request with the same button/key combination on the same window. When using -AnyModifier +AnyModifier or -AnyButton , +AnyButton, the request fails completely (no grabs are established), and an -Access +Access error is generated if there is a conflicting grab for any combination. The request has no effect on an active grab. @@ -4787,7 +4787,7 @@ The request has no effect on an active grab. Errors: -Value , +Value, Window @@ -4801,11 +4801,11 @@ Errors: This request releases the passive button/key combination on the specified window if it was grabbed by this client. A modifiers argument of -AnyModifier +AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no modifiers). A button of -AnyButton +AnyButton is equivalent to issuing the request for all possible buttons. The request has no effect on an active grab. @@ -4841,7 +4841,7 @@ The request has no effect on an active grab. Errors: -Cursor , +Cursor, Value @@ -4856,10 +4856,10 @@ This request changes the specified dynamic parameters if the pointer is actively grabbed by the client and the specified time is no earlier than the last-pointer-grab time and no later than the current server time. The interpretation of event-mask and cursor are the same as in -GrabPointer . +GrabPointer. This request has no effect on the parameters of any passive grabs established with -GrabButton . +GrabButton. @@ -4884,8 +4884,8 @@ with pointer-mode, keyboard-mode: -{ Synchronous , -Asynchronous } +{ Synchronous, +Asynchronous} @@ -4904,11 +4904,11 @@ with status: -{ Success , -AlreadyGrabbed , -Frozen , -InvalidTime , -NotViewable } +{ Success, +AlreadyGrabbed, +Frozen, +InvalidTime, +NotViewable} @@ -4916,7 +4916,7 @@ status: Errors: -Value , +Value, Window @@ -4933,73 +4933,73 @@ This request overrides any active keyboard grab by this client. If owner-events is -False , +False, all generated key events are reported with respect to grab-window. If owner-events is -True +True and if a generated key event would normally be reported to this client, it is reported normally. Otherwise, the event is reported with respect to the grab-window. Both -KeyPress +KeyPress and -KeyRelease +KeyRelease events are always reported, independent of any event selection made by the client. If keyboard-mode is -Asynchronous , +Asynchronous, keyboard event processing continues normally. If the keyboard is currently frozen by this client, then processing of keyboard events is resumed. If keyboard-mode is -Synchronous , +Synchronous, the state of the keyboard (as seen by means of the protocol) appears to freeze. No further keyboard events are generated by the server until the grabbing client issues a releasing -AllowEvents +AllowEvents request or until the keyboard grab is released. Actual keyboard changes are not lost while the keyboard is frozen. They are simply queued for later processing. If pointer-mode is -Asynchronous , +Asynchronous, pointer event processing is unaffected by activation of the grab. If pointer-mode is -Synchronous , +Synchronous, the state of the pointer (as seen by means of the protocol) appears to freeze. No further pointer events are generated by the server until the grabbing client issues a releasing -AllowEvents +AllowEvents request or until the keyboard grab is released. Actual pointer changes are not lost while the pointer is frozen. They are simply queued for later processing. This request generates -FocusIn +FocusIn and -FocusOut +FocusOut events. The request fails with status -AlreadyGrabbed +AlreadyGrabbed if the keyboard is actively grabbed by some other client. The request fails with status -Frozen +Frozen if the keyboard is frozen by an active grab of another client. The request fails with status -NotViewable +NotViewable if grab-window is not viewable. The request fails with status -InvalidTime +InvalidTime if the specified time is earlier than the last-keyboard-grab time or later than the current server time. Otherwise, the last-keyboard-grab time is set to the specified time with -CurrentTime +CurrentTime replaced by the current server time. @@ -5027,23 +5027,23 @@ replaced by the current server time. This request releases the keyboard if this client has it actively grabbed (as a result of either -GrabKeyboard +GrabKeyboard or -GrabKey ) +GrabKey) and releases any queued events. The request has no effect if the specified time is earlier than the last-keyboard-grab time or is later than the current server time. This request generates -FocusIn +FocusIn and -FocusOut +FocusOut events. An -UngrabKeyboard +UngrabKeyboard is performed automatically if the event window for an active keyboard grab becomes not viewable. @@ -5082,8 +5082,8 @@ becomes not viewable. pointer-mode, keyboard-mode: -{ Synchronous , -Asynchronous } +{ Synchronous, +Asynchronous} @@ -5091,8 +5091,8 @@ becomes not viewable. Errors: -Access , -Value , +Access, +Value, Window @@ -5106,12 +5106,12 @@ Errors: This request establishes a passive grab on the keyboard. In the future, the keyboard is actively grabbed as described in -GrabKeyboard , +GrabKeyboard, the last-keyboard-grab time is set to the time at which the key was pressed (as transmitted in the -KeyPress +KeyPress event), and the -KeyPress +KeyPress event is reported if all of the following conditions are true: The keyboard is not grabbed and the specified key @@ -5127,7 +5127,7 @@ on any ancestor of grab-window. The interpretation of the remaining arguments is the same as for -GrabKeyboard . +GrabKeyboard. The active grab is terminated automatically when the logical state of the keyboard has the specified key released, independent of the logical state of modifier keys. @@ -5138,32 +5138,32 @@ may lag the physical state if device event processing is frozen. This request overrides all previous passive grabs by the same client on the same key combinations on the same window. A modifier of -AnyModifier +AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no modifiers). It is not required that all modifiers specified have currently assigned keycodes. A key of -AnyKey +AnyKey is equivalent to issuing the request for all possible keycodes. Otherwise, the key must be in the range specified by min-keycode and max-keycode in the connection setup (or a -Value +Value error results). An -Access +Access error is generated if some other client has issued a -GrabKey +GrabKey with the same key combination on the same window. When using -AnyModifier +AnyModifier or -AnyKey , +AnyKey, the request fails completely (no grabs are established), and an -Access +Access error is generated if there is a conflicting grab for any combination. @@ -5198,7 +5198,7 @@ error is generated if there is a conflicting grab for any combination. Errors: -Value , +Value, Window @@ -5212,11 +5212,11 @@ Errors: This request releases the key combination on the specified window if it was grabbed by this client. A modifiers argument of -AnyModifier +AnyModifier is equivalent to issuing the request for all possible modifier combinations (including the combination of no modifiers). A key of -AnyKey +AnyKey is equivalent to issuing the request for all possible keycodes. This request has no effect on an active grab. @@ -5233,18 +5233,18 @@ This request has no effect on an active grab. mode: -{ AsyncPointer , -SyncPointer , -ReplayPointer , -AsyncKeyboard , +{ AsyncPointer, +SyncPointer, +ReplayPointer, +AsyncKeyboard, -SyncKeyboard , -ReplayKeyboard , -AsyncBoth , -SyncBoth } +SyncKeyboard, +ReplayKeyboard, +AsyncBoth, +SyncBoth} @@ -5276,45 +5276,45 @@ or if the specified time is later than the current server time. For -AsyncPointer , +AsyncPointer, if the pointer is frozen by the client, pointer event processing continues normally. If the pointer is frozen twice by the client on behalf of two separate grabs, -AsyncPointer +AsyncPointer thaws for both. -AsyncPointer +AsyncPointer has no effect if the pointer is not frozen by the client, but the pointer need not be grabbed by the client. For -SyncPointer , +SyncPointer, if the pointer is frozen and actively grabbed by the client, pointer event processing continues normally until the next -ButtonPress +ButtonPress or -ButtonRelease +ButtonRelease event is reported to the client, at which time the pointer again appears to freeze. However, if the reported event causes the pointer grab to be released, then the pointer does not freeze. -SyncPointer +SyncPointer has no effect if the pointer is not frozen by the client or if the pointer is not grabbed by the client. For -ReplayPointer , +ReplayPointer, if the pointer is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from the activation of a -GrabButton +GrabButton or from a previous -AllowEvents +AllowEvents with mode -SyncPointer +SyncPointer but not from a -GrabPointer ), +GrabPointer), then the pointer grab is released and that event is completely reprocessed, this time ignoring any passive grabs at or above (towards the root) the grab-window of the grab just released. @@ -5323,45 +5323,45 @@ or if the pointer is not frozen as the result of an event. For -AsyncKeyboard , +AsyncKeyboard, if the keyboard is frozen by the client, keyboard event processing continues normally. If the keyboard is frozen twice by the client on behalf of two separate grabs, -AsyncKeyboard +AsyncKeyboard thaws for both. -AsyncKeyboard +AsyncKeyboard has no effect if the keyboard is not frozen by the client, but the keyboard need not be grabbed by the client. For -SyncKeyboard , +SyncKeyboard, if the keyboard is frozen and actively grabbed by the client, keyboard event processing continues normally until the next -KeyPress +KeyPress or -KeyRelease +KeyRelease event is reported to the client, at which time the keyboard again appears to freeze. However, if the reported event causes the keyboard grab to be released, then the keyboard does not freeze. -SyncKeyboard +SyncKeyboard has no effect if the keyboard is not frozen by the client or if the keyboard is not grabbed by the client. For -ReplayKeyboard , +ReplayKeyboard, if the keyboard is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from the activation of a -GrabKey +GrabKey or from a previous -AllowEvents +AllowEvents with mode -SyncKeyboard +SyncKeyboard but not from a -GrabKeyboard ), +GrabKeyboard), then the keyboard grab is released and that event is completely reprocessed, this time ignoring any passive grabs at or above (towards the root) the grab-window of the grab just released. @@ -5370,14 +5370,14 @@ or if the keyboard is not frozen as the result of an event. For -SyncBoth , +SyncBoth, if both pointer and keyboard are frozen by the client, event processing (for both devices) continues normally until the next -ButtonPress , -ButtonRelease , -KeyPress , +ButtonPress, +ButtonRelease, +KeyPress, or -KeyRelease +KeyRelease event is reported to the client for a grabbed device (button event for the pointer, key event for the keyboard), at which time the devices again appear to freeze. @@ -5385,36 +5385,36 @@ However, if the reported event causes the grab to be released, then the devices do not freeze (but if the other device is still grabbed, then a subsequent event for it will still cause both devices to freeze). -SyncBoth +SyncBoth has no effect unless both pointer and keyboard are frozen by the client. If the pointer or keyboard is frozen twice by the client on behalf of two separate grabs, -SyncBoth +SyncBoth thaws for both (but a subsequent freeze for -SyncBoth +SyncBoth will only freeze each device once). For -AsyncBoth , +AsyncBoth, if the pointer and the keyboard are frozen by the client, event processing for both devices continues normally. If a device is frozen twice by the client on behalf of two separate grabs, -AsyncBoth +AsyncBoth thaws for both. -AsyncBoth +AsyncBoth has no effect unless both pointer and keyboard are frozen by the client. -AsyncPointer , -SyncPointer , +AsyncPointer, +SyncPointer, and -ReplayPointer +ReplayPointer have no effect on processing of keyboard events. -AsyncKeyboard , -SyncKeyboard , +AsyncKeyboard, +SyncKeyboard, and -ReplayKeyboard +ReplayKeyboard have no effect on processing of pointer events. @@ -5426,7 +5426,7 @@ It is possible for a single device to be frozen because of both grabs. In this case, the freeze must be released on behalf of both grabs before events can again be processed. If a device is frozen twice by a single client, then a single -AllowEvents +AllowEvents releases both. @@ -5513,13 +5513,13 @@ Errors: The root window the pointer is logically on and the pointer coordinates relative to the root's origin are returned. If same-screen is -False , +False, then the pointer is not on the same screen as the argument window, child is -None , +None, and win-x and win-y are zero. If same-screen is -True , +True, then win-x and win-y are the pointer coordinates relative to the argument window's origin, and child is the child containing the pointer, if any. @@ -5604,7 +5604,7 @@ The x and y coordinates are reported relative to the origin of the window. If the start time is later than the stop time or if the start time is in the future, no events are returned. If the stop time is in the future, it is equivalent to specifying -CurrentTime . +CurrentTime. @@ -5668,7 +5668,7 @@ The src-x and src-y coordinates are taken relative to src-window's origin and are returned as dst-x and dst-y coordinates relative to dst-window's origin. If same-screen is -False , +False, then src-window and dst-window are on different screens, and dst-x and dst-y are zero. If the coordinates are contained in a mapped child of dst-window, @@ -5727,14 +5727,14 @@ Errors: If dst-window is -None , +None, this request moves the pointer by offsets [dst-x, dst-y] relative to the current position of the pointer. If dst-window is a window, this request moves the pointer to [dst-x, dst-y] relative to dst-window's origin. However, if src-window is not -None , +None, the move only takes place if src-window contains the pointer and the pointer is contained in the specified rectangle of src-window. @@ -5768,7 +5768,7 @@ moved the pointer. focus: WINDOW or -PointerRoot +PointerRoot or None @@ -5776,9 +5776,9 @@ or revert-to: -{ Parent , -PointerRoot , -None } +{ Parent, +PointerRoot, +None} @@ -5792,8 +5792,8 @@ or Errors: -Match , -Value , +Match, +Value, Window @@ -5809,12 +5809,12 @@ The request has no effect if the specified time is earlier than the current last-focus-change time or is later than the current server time. Otherwise, the last-focus-change time is set to the specified time with -CurrentTime +CurrentTime replaced by the current server time. If -None +None is specified as the focus, all keyboard events are discarded until a new focus window is set. In this case, the revert-to argument is ignored. @@ -5828,7 +5828,7 @@ Otherwise, the event is reported with respect to the focus window. If -PointerRoot +PointerRoot is specified as the focus, the focus window is dynamically taken to be the root window of whatever screen the pointer is on at each keyboard event. @@ -5837,31 +5837,31 @@ the revert-to argument is ignored. This request generates -FocusIn +FocusIn and -FocusOut +FocusOut events. The specified focus window must be viewable at the time of the request (or a -Match +Match error results). If the focus window later becomes not viewable, the new focus window depends on the revert-to argument. If revert-to is -Parent , +Parent, the focus reverts to the parent (or the closest viewable ancestor) and the new revert-to value is taken to be -None . +None. If revert-to is -PointerRoot +PointerRoot or -None , +None, the focus reverts to that value. When the focus reverts, -FocusIn +FocusIn and -FocusOut +FocusOut events are generated, but the last-focus-change time is not affected. @@ -5883,7 +5883,7 @@ but the last-focus-change time is not affected. focus: WINDOW or -PointerRoot +PointerRoot or None @@ -5891,9 +5891,9 @@ or revert-to: -{ Parent , -PointerRoot , -None } +{ Parent, +PointerRoot, +None} @@ -5965,8 +5965,8 @@ may lag the physical state if device event processing is frozen. Errors: -Alloc , -IDChoice , +Alloc, +IDChoice, Name @@ -6071,8 +6071,8 @@ T{ FONTINFO: T} T{ [draw-direction: -{ LeftToRight , -RightToLeft } +{ LeftToRight, +RightToLeft} T} \ min-char-or-byte2, max-char-or-byte2: CARD16 \ min-byte1, max-byte1: CARD8 @@ -6116,9 +6116,9 @@ the currently contained font is used. The draw-direction is just a hint and indicates whether most char-infos have a positive, -LeftToRight , +LeftToRight, or a negative, -RightToLeft , +RightToLeft, character-width metric. The core protocol defines no support for vertical text. @@ -6157,7 +6157,7 @@ That is, all glyphs in the specified linear or matrix range have the same information, as given by min-bounds (and max-bounds). If all-chars-exist is -True , +True, then all characters in char-infos have nonzero bounding boxes. @@ -6285,8 +6285,8 @@ server-dependent. draw-direction: -{ LeftToRight , -RightToLeft } +{ LeftToRight, +RightToLeft} @@ -6345,7 +6345,7 @@ If a gcontext is given for font, the currently contained font is used. The draw-direction, font-ascent, and font-descent are the same as described in -QueryFont . +QueryFont. The overall-ascent is the maximum of the ascent metrics of all characters in the string, and the overall-descent is the maximum of the descent metrics. The overall-width is the sum of the character-width metrics of all characters @@ -6410,7 +6410,7 @@ names: LISTofSTRING8 This request returns a list of available font names (as controlled by the font search path; see -SetFontPath +SetFontPath request) that match the pattern. At most, max-names names will be returned. @@ -6486,10 +6486,10 @@ FONTINFO: <same type definition as in This request is similar to -ListFonts , +ListFonts, but it also returns information about each font. The information returned for each font is identical to what -QueryFont +QueryFont would return except that the per-character metrics are not returned. Note that this request can generate multiple replies. With each reply, @@ -6613,9 +6613,9 @@ This request returns the current search path for fonts. Errors: -Alloc , -Drawable , -IDChoice , +Alloc, +Drawable, +IDChoice, Value @@ -6628,17 +6628,17 @@ Errors: This request creates a pixmap and assigns the identifier pid to it. The width and height must be nonzero (or a -Value +Value error results). The depth must be one of the depths supported by the root of the specified drawable (or a -Value +Value error results). The initial contents of the pixmap are undefined. It is legal to pass an -InputOnly +InputOnly window as a drawable to this request. @@ -6709,12 +6709,12 @@ The pixmap storage will be freed when no other resource references it. Errors: -Alloc , -Drawable , -Font , -IDChoice , -Match , -Pixmap , +Alloc, +Drawable, +Font, +IDChoice, +Match, +Pixmap, Value @@ -6730,7 +6730,7 @@ and assigns the identifier cid to it. The gcontext can be used with any destination drawable having the same root and depth as the specified drawable; use with other drawables results in a -Match +Match error. @@ -7118,7 +7118,7 @@ The full path of the line is drawn. The full path of the line is drawn, but the even dashes are filled differently than the odd dashes (see fill-style), with -Butt +Butt cap-style used where even and odd dashes meet. @@ -7174,7 +7174,7 @@ line) with no projection beyond. The result is a circular arc with its diameter equal to the line-width, centered on the endpoint; it is equivalent to -Butt +Butt for line-width zero. @@ -7212,7 +7212,7 @@ The join-style defines how corners are drawn for wide lines: The outer edges of the two lines extend to meet at an angle. However, if the angle is less than 11 degrees, a -Bevel +Bevel join-style is used instead. @@ -7231,7 +7231,7 @@ centered on the joinpoint. The result is -Butt +Butt endpoint styles, and then the triangular notch is filled. @@ -7344,16 +7344,16 @@ request. The tile pixmap must have the same root and depth as the gcontext (or a -Match +Match error results). The stipple pixmap must have depth one and must have the same root as the gcontext (or a -Match +Match error results). For fill-style -Stippled +Stippled (but not fill-style -OpaqueStippled ), +OpaqueStippled), the stipple pattern is tiled in a single plane and acts as an additional clip mask to be ANDed with the clip-mask. Any size pixmap can be used for tiling or stippling, @@ -7463,15 +7463,15 @@ For the odd dashes for line requests with line-style The dashes value allowed here is actually a simplified form of the more general patterns that can be set with -SetDashes . +SetDashes. Specifying a value of N here is equivalent to specifying the two element list [N, N] in -SetDashes . +SetDashes. The value must be nonzero (or a -Value +Value error results). The meaning of dash-offset and dashes are explained in the -SetDashes +SetDashes request. @@ -7485,28 +7485,28 @@ The clip-mask origin is interpreted relative to the origin of whatever destination drawable is specified in a graphics request. If a pixmap is specified as the clip-mask, it must have depth 1 and have the same root as the gcontext (or a -Match +Match error results). If clip-mask is -None , +None, then pixels are always drawn, regardless of the clip origin. The clip-mask can also be set with the -SetClipRectangles +SetClipRectangles request. For -ClipByChildren , +ClipByChildren, both source and destination windows are additionally clipped by all viewable -InputOutput +InputOutput children. For -IncludeInferiors , +IncludeInferiors, neither source nor destination window is clipped by inferiors. This will result in including subwindow contents in the source and drawing through subwindow boundaries of the destination. The use of -IncludeInferiors +IncludeInferiors with a source or destination window of one depth with mapped inferiors of differing depth is not illegal, but the semantics is undefined by the core protocol. @@ -7514,13 +7514,13 @@ but the semantics is undefined by the core protocol. The fill-rule defines what pixels are inside (that is, are drawn) for paths given in -FillPoly +FillPoly requests. -EvenOdd +EvenOdd means a point is inside if an infinite ray with the point as origin crosses the path an odd number of times. For -Winding , +Winding, a point is inside if an infinite ray with the point as origin crosses an unequal number of clockwise and counterclockwise directed path segments. A clockwise directed path segment is one that crosses the ray from left @@ -7545,16 +7545,16 @@ and are inside if and only if the polygon interior is immediately below The arc-mode controls filling in the -PolyFillArc +PolyFillArc request. The graphics-exposures flag controls -GraphicsExposure +GraphicsExposure event generation for -CopyArea +CopyArea and -CopyPlane +CopyPlane requests (and any similar requests defined by extensions). @@ -7736,11 +7736,11 @@ changes to a single gcontext. Errors: -Alloc , -Font , -GContext , -Match , -Pixmap , +Alloc, +Font, +GContext, +Match, +Pixmap, Value @@ -7755,14 +7755,14 @@ This request changes components in gc. The value-mask and value-list specify which components are to be changed. The values and restrictions are the same as for -CreateGC . +CreateGC. Changing the clip-mask also overrides any previous -SetClipRectangles +SetClipRectangles request on the context. Changing dash-offset or dashes overrides any previous -SetDashes +SetDashes request on the context. @@ -7795,9 +7795,9 @@ a subset of the components may have been altered. Errors: -Alloc , -GContext , -Match , +Alloc, +GContext, +Match, Value @@ -7810,9 +7810,9 @@ Errors: This request copies components from src-gc to dst-gc. The value-mask specifies which components to copy, as for -CreateGC . +CreateGC. The two gcontexts must have the same root and the same depth (or a -Match +Match error results). @@ -7845,8 +7845,8 @@ error results). Errors: -Alloc , -GContext , +Alloc, +GContext, Value @@ -7859,7 +7859,7 @@ Errors: This request sets dash-offset and dashes in gc for dashed line styles. Dashes cannot be empty (or a -Value +Value error results). Specifying an odd-length list is equivalent to specifying the same list concatenated with itself to produce an even-length list. @@ -7867,7 +7867,7 @@ The initial and alternating elements of dashes are the even dashes; the others are the odd dashes. Each element specifies a dash length in pixels. All of the elements must be nonzero (or a -Value +Value error results). The dash-offset defines the phase of the pattern, specifying how many pixels into dashes the pattern should actually begin in @@ -7895,17 +7895,17 @@ of the dash, the direction of the dash, and the dash length. For any graphics primitive, the total set of pixels used to render the primitive (both even and odd numbered dash elements) with -DoubleDash +DoubleDash line-style is the same as the set of pixels used to render the primitive with -Solid +Solid line-style. For any graphics primitive, if the primitive is drawn with -OnOffDash +OnOffDash or -DoubleDash +DoubleDash line-style unclipped at position [x,y] and again at position [x+dx,y+dy], then a point [x1,y1] is included in a dash in the first instance if and only if the point [x1+dx,y1+dy] is included in the dash in @@ -7942,10 +7942,10 @@ would be included in the dash when drawn unclipped. ordering: -{ UnSorted , -YSorted , -YXSorted , -YXBanded } +{ UnSorted, +YSorted, +YXSorted, +YXBanded} @@ -7953,9 +7953,9 @@ would be included in the dash when drawn unclipped. Errors: -Alloc , -GContext , -Match , +Alloc, +GContext, +Match, Value @@ -7977,11 +7977,11 @@ undefined. Note that the list of rectangles can be empty, which effectively disables output. This is the opposite of passing -None +None as the clip-mask in -CreateGC +CreateGC and -ChangeGC . +ChangeGC. If known by the client, @@ -7990,22 +7990,22 @@ argument. This may provide faster operation by the server. If an incorrect ordering is specified, the server may generate a -Match +Match error, but it is not required to do so. If no error is generated, the graphics results are undefined. -UnSorted +UnSorted means that the rectangles are in arbitrary order. -YSorted +YSorted means that the rectangles are nondecreasing in their Y origin. -YXSorted +YXSorted additionally constrains -YSorted +YSorted order in that all rectangles with an equal Y origin are nondecreasing in their X origin. -YXBanded +YXBanded additionally constrains -YXSorted +YXSorted by requiring that, for every possible Y scanline, all rectangles that include that scanline have identical Y origins and Y extents. @@ -8078,9 +8078,9 @@ and destroys the gcontext. Errors: -Match , -Value , -Window +Match, +Value, +Window @@ -8098,23 +8098,23 @@ If height is zero, it is replaced with the current height of the window minus y. If the window has a defined background tile, the rectangle is tiled with a plane-mask of all ones and function of -Copy +Copy and a subwindow-mode of -ClipByChildren . +ClipByChildren. If the window has background -None , +None, the contents of the window are not changed. In either case, if exposures is -True , +True, then one or more exposure events are generated for regions of the rectangle that are either visible or are being retained in a backing store. It is a -Match +Match error to use an -InputOnly +InputOnly window in this request. @@ -8157,8 +8157,8 @@ window in this request. Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8176,7 +8176,7 @@ The dst-x and dst-y are relative to dst-drawable's origin, each pair specifying the upper-left corner of the rectangle. The src-drawable must have the same root and the same depth as dst-drawable (or a -Match +Match error results). @@ -8187,26 +8187,26 @@ then those regions are not copied, but the following occurs on all corresponding destination regions that are either visible or are retained in backing-store. If the dst-drawable is a window with a background other than -None , +None, these corresponding destination regions are tiled (with plane-mask of all ones and function -Copy ) +Copy) with that background. Regardless of tiling and whether the destination is a window or a pixmap, if graphics-exposures in gc is -True , +True, then -GraphicsExposure +GraphicsExposure events for all corresponding destination regions are generated. If graphics-exposures is -True +True but no -GraphicsExposure +GraphicsExposure events are generated, then a -NoExposure +NoExposure event is generated. @@ -8258,9 +8258,9 @@ graphics-exposures, clip-x-origin, clip-y-origin, clip-mask Errors: -Drawable , -GContext , -Match , +Drawable, +GContext, +Match, Value @@ -8272,22 +8272,22 @@ Errors: The src-drawable must have the same root as dst-drawable (or a -Match +Match error results), but it need not have the same depth. The bit-plane must have exactly one bit set to 1 and the value of bit-plane must be less than %2 sup n% where n is the depth of src-drawable (or a -Value +Value error results). Effectively, a pixmap of the same depth as dst-drawable and with size specified by the source region is formed using the foreground/background pixels in gc (foreground everywhere the bit-plane in src-drawable contains a bit set to 1, background everywhere the bit-plane contains a bit set to 0), and the equivalent of a -CopyArea +CopyArea is performed, with all the same exposure semantics. This can also be thought of as using the specified region of the source bit-plane as a stipple with a fill-style of -OpaqueStippled +OpaqueStippled for filling a rectangular area of the destination. @@ -8318,8 +8318,8 @@ clip-mask coordinate-mode: -{ Origin , -Previous } +{ Origin, +Previous} @@ -8332,9 +8332,9 @@ clip-mask Errors: -Drawable , -GContext , -Match , +Drawable, +GContext, +Match, Value @@ -8381,8 +8381,8 @@ clip-x-origin, clip-y-origin, clip-mask coordinate-mode: -{ Origin , -Previous } +{ Origin, +Previous} @@ -8395,9 +8395,9 @@ clip-x-origin, clip-y-origin, clip-mask Errors: -Drawable , -GContext , -Match , +Drawable, +GContext, +Match, Value @@ -8421,7 +8421,7 @@ If thin (zero line-width) lines intersect, the intersecting pixels are drawn multiple times. If wide lines intersect, the intersecting pixels are drawn only once, as though the entire -PolyLine +PolyLine were a single filled shape. @@ -8431,7 +8431,7 @@ depending on the coordinate-mode. When either of the two lines involved in a -Bevel +Bevel join is neither vertical nor horizontal, then the slope and position of the line segment defining the bevel join edge is implementation dependent. However, the computation @@ -8491,8 +8491,8 @@ SEGMENT: [x1, y1, x2, y2: INT16] Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8551,8 +8551,8 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8564,7 +8564,7 @@ Errors: This request draws the outlines of the specified rectangles, as if a five-point -PolyLine +PolyLine were specified for each rectangle: @@ -8622,8 +8622,8 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8672,7 +8672,7 @@ tangent of the circle/ellipse at the endpoint. When the angle of an arc face is not an integral multiple of 90 degrees, and the width and height of the arc are both are nonzero, then the shape and position of the cap at that face is implementation dependent. However, for a -Butt +Butt cap, the face is defined by a straight line, and the computation of the position (relative to the center of the arc) and the slope of the line only @@ -8779,16 +8779,16 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes shape: -{ Complex , -Nonconvex , -Convex } +{ Complex, +Nonconvex, +Convex} coordinate-mode: -{ Origin , -Previous } +{ Origin, +Previous} @@ -8801,9 +8801,9 @@ tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes Errors: -Drawable , -GContext , -Match , +Drawable, +GContext, +Match, Value @@ -8826,36 +8826,36 @@ depending on the coordinate-mode. The shape parameter may be used by the server to improve performance. -Complex +Complex means the path may self-intersect. Contiguous coincident points in the path are not treated as self-intersection. -Nonconvex +Nonconvex means the path does not self-intersect, but the shape is not wholly convex. If known by the client, specifying -Nonconvex +Nonconvex over -Complex +Complex may improve performance. If -Nonconvex +Nonconvex is specified for a self-intersecting path, the graphics results are undefined. -Convex +Convex means that for every pair of points inside the polygon, the line segment connecting them does not intersect the path. If known by the client, specifying -Convex +Convex can improve performance. If -Convex +Convex is specified for a path that is not convex, the graphics results are undefined. @@ -8897,8 +8897,8 @@ tile-stipple-x-origin, tile-stipple-y-origin Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8910,7 +8910,7 @@ Errors: This request fills the specified rectangles, as if a four-point -FillPoly +FillPoly were specified for each rectangle: [x,y] [x+width,y] [x+width,y+height] [x,y+height] @@ -8965,8 +8965,8 @@ tile-stipple-x-origin, tile-stipple-y-origin Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -8982,10 +8982,10 @@ this request fills the region closed by the infinitely thin path described by the specified arc and one or two line segments, depending on the arc-mode. For -Chord , +Chord, the single line segment joining the endpoints of the arc is used. For -PieSlice , +PieSlice, the two line segments joining the endpoints of the arc with the center point are used. @@ -8999,15 +8999,15 @@ they are not truncated to discrete coordinates. The arc angles are interpreted as specified in the -PolyArc +PolyArc request. When the angle of an arc face is not an integral multiple of 90 degrees, then the precise endpoint on the arc is implementation dependent. However, for -Chord +Chord arc-mode, the computation of the pair of endpoints (relative to the center of the arc) only depends on the width and height of the arc and the angles of the two arc faces. For -PieSlice +PieSlice arc-mode, the computation of an endpoint only depends on the angle of the arc face for that endpoint and the ratio of the arc width to arc height. @@ -9070,9 +9070,9 @@ tile-stipple-x-origin, tile-stipple-y-origin format: -{ Bitmap , -XYPixmap , -ZPixmap } +{ Bitmap, +XYPixmap, +ZPixmap} @@ -9085,9 +9085,9 @@ tile-stipple-x-origin, tile-stipple-y-origin Errors: -Drawable , -GContext , -Match , +Drawable, +GContext, +Match, Value @@ -9103,43 +9103,43 @@ The dst-x and dst-y coordinates are relative to the drawable's origin. If -Bitmap +Bitmap format is used, then depth must be one (or a -Match +Match error results), and the image must be in XY format. The foreground pixel in gc defines the source for bits set to 1 in the image, and the background pixel defines the source for the bits set to 0. For -XYPixmap +XYPixmap and -ZPixmap , +ZPixmap, the depth must match the depth of the drawable (or a -Match +Match error results). For -XYPixmap , +XYPixmap, the image must be sent in XY format. For -ZPixmap , +ZPixmap, the image must be sent in the Z format defined for the given depth. The left-pad must be zero for -ZPixmap +ZPixmap format (or a -Match +Match error results). For -Bitmap +Bitmap and -XYPixmap +XYPixmap format, left-pad must be less than bitmap-scanline-pad as given in the server connection setup information (or a -Match +Match error results). The first left-pad bits in every scanline are to be ignored by the server. The actual image begins that many bits into the data. @@ -9186,8 +9186,8 @@ GC mode-dependent components: foreground, background format: -{ XYPixmap , -ZPixmap } +{ XYPixmap, +ZPixmap} @@ -9218,8 +9218,8 @@ data: LISTofBYTE Errors: -Drawable , -Match , +Drawable, +Match, Value @@ -9235,13 +9235,13 @@ given format. The x and y coordinates are relative to the drawable's origin and define the upper-left corner of the rectangle. If -XYPixmap +XYPixmap is specified, only the bit planes specified in plane-mask are transmitted, with the planes appearing from most significant to least significant in bit order. If -ZPixmap +ZPixmap is specified, then bits in all planes not specified in plane-mask are transmitted as zero. Range checking is not performed on plane-mask; @@ -9253,12 +9253,12 @@ If the drawable is a window, its visual type is returned. If the drawable is a pixmap, the visual is -None . +None. If the drawable is a pixmap, then the given rectangle must be wholly contained within the pixmap (or a -Match +Match error results). If the drawable is a window, the window must be viewable, @@ -9266,7 +9266,7 @@ and it must be the case that, if there were no inferiors or overlapping windows, the specified rectangle of the window would be fully visible on the screen and wholly contained within the outside edges of the window (or a -Match +Match error results). Note that the borders of the window can be included and read with this request. If the window has a backing store, @@ -9338,10 +9338,10 @@ TEXTELT8: [delta: INT8 Errors: -Drawable , -Font , -GContext , -Match +Drawable, +Font, +GContext, +Match @@ -9368,7 +9368,7 @@ All contained FONTs are always transmitted most significant byte first. If a -Font +Font error is generated for an item, the previous items may have been drawn. @@ -9441,9 +9441,9 @@ TEXTELT16: [delta: INT8 Errors: -Drawable , -Font , -GContext , +Drawable, +Font, +GContext, Match @@ -9455,7 +9455,7 @@ Errors: This request is similar to -PolyText8 , +PolyText8, except 2-byte (or 16-bit) characters are used. For fonts defined with linear indexing rather than 2-byte matrix indexing, the server will interpret each CHAR2B as a 16-bit number that @@ -9497,8 +9497,8 @@ CHAR2B is taken as the most significant byte). Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -9533,15 +9533,15 @@ font-ascent + font-descent The overall-width, font-ascent, and font-descent are as they would be returned by a -QueryTextExtents +QueryTextExtents call using gc and string. The function and fill-style defined in gc are ignored for this request. The effective function is -Copy , +Copy, and the effective fill-style -Solid . +Solid. For fonts defined with 2-byte matrix indexing, @@ -9587,8 +9587,8 @@ subwindow-mode, clip-x-origin, clip-y-origin, clip-mask Errors: -Drawable , -GContext , +Drawable, +GContext, Match @@ -9600,7 +9600,7 @@ Errors: This request is similar to -ImageText8 , +ImageText8, except 2-byte (or 16-bit) characters are used. For fonts defined with linear indexing rather than 2-byte matrix indexing, the server will interpret each CHAR2B as a 16-bit number that @@ -9635,8 +9635,8 @@ CHAR2B is taken as the most significant byte). alloc: -{ None , -All } +{ None, +All} @@ -9644,11 +9644,11 @@ CHAR2B is taken as the most significant byte). Errors: -Alloc , -IDChoice , -Match , -Value , -Window +Alloc, +IDChoice, +Match, +Value, +Window @@ -9661,59 +9661,59 @@ Errors: This request creates a colormap of the specified visual type for the screen on which the window resides and associates the identifier mid with it. The visual type must be one supported by the screen (or a -Match +Match error results). The initial values of the colormap entries are undefined for classes -GrayScale , -PseudoColor , +GrayScale, +PseudoColor, and -DirectColor . +DirectColor. For -StaticGray , -StaticColor , +StaticGray, +StaticColor, and -TrueColor , +TrueColor, the entries will have defined values, but those values are specific to the visual and are not defined by the core protocol. For -StaticGray , -StaticColor , +StaticGray, +StaticColor, and -TrueColor , +TrueColor, alloc must be specified as -None +None (or a -Match +Match error results). For the other classes, if alloc is -None , +None, the colormap initially has no allocated entries, and clients can allocate entries. If alloc is -All , +All, then the entire colormap is allocated writable. The initial values of all allocated entries are undefined. For -GrayScale +GrayScale and -PseudoColor , +PseudoColor, the effect is as if an -AllocColorCells +AllocColorCells request returned all pixel values from zero to N - 1, where N is the colormap-entries value in the specified visual. For -DirectColor , +DirectColor, the effect is as if an -AllocColorPlanes +AllocColorPlanes request returned a pixel value of zero and red-mask, green-mask, and blue-mask values containing the same bits as the corresponding masks in the specified visual. However, in all cases, none of these entries can be freed with -FreeColors . +FreeColors. @@ -9749,19 +9749,19 @@ This request deletes the association between the resource ID and the colormap and frees the colormap storage. If the colormap is an installed map for a screen, it is uninstalled (see -UninstallColormap +UninstallColormap request). If the colormap is defined as the colormap for a window (by means of -CreateWindow +CreateWindow or -ChangeWindowAttributes ), +ChangeWindowAttributes), the colormap for the window is changed to -None , +None, and a -ColormapNotify +ColormapNotify event is generated. The protocol does not define the colors displayed for a window with a colormap of -None . +None. This request has no effect on a default colormap for a screen. @@ -9786,8 +9786,8 @@ This request has no effect on a default colormap for a screen. Errors: -Alloc , -Colormap , +Alloc, +Colormap, IDChoice @@ -9807,21 +9807,21 @@ and their read-only or writable characteristics intact, and it frees those entries in src-cmap. Color values in other entries in the new colormap are undefined. If src-cmap was created by the client with alloc -All +All (see -CreateColormap +CreateColormap request), then the new colormap is also created with alloc -All , +All, all color values for all entries are copied from src-cmap, and then all entries in src-cmap are freed. If src-cmap was not created by the client with alloc -All , +All, then the allocations to be moved are all those pixels and planes that have been allocated by the client using either -AllocColor , -AllocNamedColor , -AllocColorCells , +AllocColor, +AllocNamedColor, +AllocColorCells, or AllocColorPlanes and that have not been freed since they were allocated. @@ -9866,12 +9866,12 @@ except that the required list must remain installed. If cmap is not already an installed map, a -ColormapNotify +ColormapNotify event is generated on every window having cmap as an attribute. In addition, for every other colormap that is installed or uninstalled as a result of the request, a -ColormapNotify +ColormapNotify event is generated on every window having that colormap as an attribute. @@ -9882,11 +9882,11 @@ where M is the min-installed-maps specified for the screen in the connection setup. The required list is maintained as follows. When a colormap is an explicit argument to -InstallColormap , +InstallColormap, it is added to the head of the list; the list is truncated at the tail, if necessary, to keep the length of the list to at most M. When a colormap is an explicit argument to -UninstallColormap +UninstallColormap and it is in the required list, it is removed from the list. A colormap is not added to the required list when it is installed implicitly by the server, and the server cannot implicitly uninstall a colormap that is @@ -9927,7 +9927,7 @@ Errors: If cmap is on the required list for its screen (see -InstallColormap +InstallColormap request), it is removed from the list. As a side effect, @@ -9938,12 +9938,12 @@ except that the required list must remain installed. If cmap becomes uninstalled, a -ColormapNotify +ColormapNotify event is generated on every window having cmap as an attribute. In addition, for every other colormap that is installed or uninstalled as a result of the request, a -ColormapNotify +ColormapNotify event is generated on every window having that colormap as an attribute. @@ -9992,7 +9992,7 @@ This request returns a list of the currently installed colormaps for the screen of the specified window. The order of colormaps is not significant, and there is no explicit indication of the required list (see -InstallColormap +InstallColormap request). @@ -10037,8 +10037,8 @@ red, green, blue: CARD16 Errors: -Alloc , -Colormap +Alloc, +Colormap @@ -10101,8 +10101,8 @@ visual-red, visual-green, visual-blue: CARD16 Errors: -Alloc , -Colormap , +Alloc, +Colormap, Name @@ -10116,7 +10116,7 @@ Errors: This request looks up the named color with respect to the screen associated with the colormap. Then, it does an -AllocColor +AllocColor on cmap. The name should use the ISO Latin-1 encoding, and uppercase and lowercase do not matter. @@ -10165,8 +10165,8 @@ pixels, masks: LISTofCARD32 Errors: -Alloc , -Colormap , +Alloc, +Colormap, Value @@ -10179,7 +10179,7 @@ Errors: The number of colors must be positive, and the number of planes must be nonnegative (or a -Value +Value error results). If C colors and P planes are requested, then C pixels and P masks are returned. @@ -10189,21 +10189,21 @@ By ORing together masks and pixels, C*%2 sup P% distinct pixels can be produced; all of these are allocated writable by the request. For -GrayScale +GrayScale or -PseudoColor , +PseudoColor, each mask will have exactly one bit set to 1; for -DirectColor , +DirectColor, each will have exactly three bits set to 1. If contiguous is -True +True and if all masks are ORed together, a single contiguous set of bits will be formed for -GrayScale +GrayScale or -PseudoColor , +PseudoColor, and three contiguous sets of bits (one within each pixel subfield) for -DirectColor . +DirectColor. The RGB values of the allocated entries are undefined. @@ -10253,8 +10253,8 @@ red-mask, green-mask, blue-mask: CARD32 Errors: -Alloc , -Colormap , +Alloc, +Colormap, Value @@ -10267,18 +10267,18 @@ Errors: The number of colors must be positive, and the reds, greens, and blues must be nonnegative (or a -Value +Value error results). If C colors, R reds, G greens, and B blues are requested, then C pixels are returned, and the masks have R, G, and B bits set, respectively. If contiguous is -True , +True, then each mask will have a contiguous set of bits. No mask will have any bits in common with any other mask or with any of the pixels. For -DirectColor , +DirectColor, each mask will lie within the corresponding pixel subfield. By ORing together subsets of masks with pixels, C*%2 sup R+G+B% distinct pixels can be produced; @@ -10289,11 +10289,11 @@ there are only C*%2 sup R% independent red entries, C*%2 sup G% independent green entries, and C*%2 sup B% independent blue entries. This is true even for -PseudoColor . +PseudoColor. When the colormap entry for a pixel value is changed using -StoreColors +StoreColors or -StoreNamedColor , +StoreNamedColor, the pixel is decomposed according to the masks and the corresponding independent entries are updated. @@ -10327,8 +10327,8 @@ corresponding independent entries are updated. Errors: -Access , -Colormap , +Access, +Colormap, Value @@ -10345,14 +10345,14 @@ The set of all pixels is produced by ORing together subsets of plane-mask with the pixels. The request frees all of these pixels that were allocated by the client (using -AllocColor , -AllocNamedColor , -AllocColorCells , +AllocColor, +AllocNamedColor, +AllocColorCells, and -AllocColorPlanes ). +AllocColorPlanes). Note that freeing an individual pixel obtained from -AllocColorPlanes +AllocColorPlanes may not actually allow it to be reused until all of its related pixels are also freed. Similarly, a read-only entry is not actually freed until it has been @@ -10364,17 +10364,17 @@ entry is actually freed. All specified pixels that are allocated by the client in cmap are freed, even if one or more pixels produce an error. A -Value +Value error is generated if a specified pixel is not a valid index into cmap. An -Access +Access error is generated if a specified pixel is not allocated by the client (that is, is unallocated or is only allocated by another client) or if the colormap was created with all entries writable (using an alloc value of -All +All in -CreateColormap ). +CreateColormap). If more than one pixel is in error, it is arbitrary as to which pixel is reported. @@ -10456,9 +10456,9 @@ the changes are visible immediately. All specified pixels that are allocated writable in cmap (by any client) are changed, even if one or more pixels produce an error. A -Value +Value error is generated if a specified pixel is not a valid index into cmap, and an -Access +Access error is generated if a specified pixel is unallocated or is allocated read-only. If more than one pixel is in error, @@ -10499,9 +10499,9 @@ it is arbitrary as to which pixel is reported. Errors: -Access , -Colormap , -Name , +Access, +Colormap, +Name, Value @@ -10514,16 +10514,16 @@ Errors: This request looks up the named color with respect to the screen associated with cmap and then does a -StoreColors +StoreColors in cmap. The name should use the ISO Latin-1 encoding, and uppercase and lowercase do not matter. The -Access +Access and -Value +Value errors are the same as in -StoreColors . +StoreColors. @@ -10576,7 +10576,7 @@ RGB: [red, green, blue: CARD16] Errors: -Colormap , +Colormap, Value @@ -10591,7 +10591,7 @@ This request returns the hardware-specific color values stored in cmap for the specified pixels. The values returned for an unallocated entry are undefined. A -Value +Value error is generated if a pixel is not a valid index into cmap. If more than one pixel is in error, it is arbitrary as to which pixel is reported. @@ -10638,7 +10638,7 @@ visual-red, visual-green, visual-blue: CARD16 Errors: -Colormap , +Colormap, Name @@ -10702,9 +10702,9 @@ and uppercase and lowercase do not matter. Errors: -Alloc , -IDChoice , -Match , +Alloc, +IDChoice, +Match, Pixmap @@ -10718,14 +10718,14 @@ Errors: This request creates a cursor and associates identifier cid with it. The foreground and background RGB values must be specified, even if the server only has a -StaticGray +StaticGray or -GrayScale +GrayScale screen. The foreground is used for the bits set to 1 in the source, and the background is used for the bits set to 0. Both source and mask (if specified) must have depth one (or a -Match +Match error results), but they can have any root. The mask pixmap defines the shape of the cursor. That is, @@ -10735,11 +10735,11 @@ the corresponding bits of the source pixmap are ignored. If no mask is given, all pixels of the source are displayed. The mask, if present, must be the same size as the source (or a -Match +Match error results). The x and y coordinates define the hotspot relative to the source's origin and must be a point within the source (or a -Match +Match error results). @@ -10801,9 +10801,9 @@ The server might or might not make a copy of the pixmap. Errors: -Alloc , -Font , -IDChoice , +Alloc, +Font, +IDChoice, Value @@ -10815,12 +10815,12 @@ Errors: This request is similar to -CreateCursor , +CreateCursor, except the source and mask bitmaps are obtained from the specified font glyphs. The source-char must be a defined glyph in source-font, and if mask-font is given, mask-char must be a defined glyph in mask-font (or a -Value +Value error results). The mask font and character are optional. The origins of the source and mask (if it is defined) glyphs @@ -10933,9 +10933,9 @@ the change is visible immediately. class: -{ Cursor , -Tile , -Stipple } +{ Cursor, +Tile, +Stipple} @@ -10965,8 +10965,8 @@ width, height: CARD16 Errors: -Drawable , -Match , +Drawable, +Match, Value @@ -10979,32 +10979,32 @@ Errors: This request returns the best size that is closest to the argument size. For -Cursor , +Cursor, this is the largest size that can be fully displayed. For -Tile , +Tile, this is the size that can be tiled fastest. For -Stipple , +Stipple, this is the size that can be stippled fastest. For -Cursor , +Cursor, the drawable indicates the desired screen. For -Tile +Tile and -Stipple , +Stipple, the drawable indicates the screen and also possibly the window class and depth. An -InputOnly +InputOnly window cannot be used as the drawable for -Tile +Tile or -Stipple +Stipple (or a -Match +Match error results). @@ -11132,9 +11132,9 @@ This request returns a list of all extensions supported by the server. status: -{ Success , -Busy , -Failed } +{ Success, +Busy, +Failed} @@ -11142,7 +11142,7 @@ status: Errors: -Alloc , +Alloc, Value @@ -11156,26 +11156,26 @@ Errors: This request specifies the keycodes (if any) of the keys to be used as modifiers. The number of keycodes in the list must be 8*keycodes-per-modifier (or a -Length +Length error results). The keycodes are divided into eight sets, with each set containing keycodes-per-modifier elements. The sets are assigned to the modifiers -Shift , -Lock , -Control , -Mod1 , -Mod2 , -Mod3 , -Mod4 , +Shift, +Lock, +Control, +Mod1, +Mod2, +Mod3, +Mod4, and -Mod5 , +Mod5, in order. Only nonzero keycode values are used within each set; zero values are ignored. All of the nonzero keycodes must be in the range specified by min-keycode and max-keycode in the connection setup (or a -Value +Value error results). The order of keycodes within a set does not matter. If no nonzero values are specified in a set, @@ -11191,7 +11191,7 @@ if certain keys do not generate up transitions in hardware, if auto-repeat cannot be disabled on certain keys, or if multiple keys per modifier are not supported). The status reply is -Failed +Failed if some such restriction is violated, and none of the modifiers is changed. @@ -11199,14 +11199,14 @@ and none of the modifiers is changed. If the new nonzero keycodes specified for a modifier differ from those currently defined and any (current or new) keys for that modifier are logically in the down state, then the status reply is -Busy , +Busy, and none of the modifiers is changed. This request generates a -MappingNotify +MappingNotify event on a -Success +Success status. @@ -11246,15 +11246,15 @@ The number of keycodes in the list is 8*keycodes-per-modifier. The keycodes are divided into eight sets, with each set containing keycodes-per-modifier elements. The sets are assigned to the modifiers -Shift , -Lock , -Control , -Mod1 , -Mod2 , -Mod3 , -Mod4 , +Shift, +Lock, +Control, +Mod1, +Mod2, +Mod3, +Mod4, and -Mod5 , +Mod5, in order. The keycodes-per-modifier value is chosen arbitrarily by the server; zeroes are used to fill in unused elements within each set. @@ -11292,7 +11292,7 @@ The order of keycodes within each set is chosen arbitrarily by the server. Errors: -Alloc , +Alloc, Value @@ -11308,11 +11308,11 @@ starting with the specified keycode. The symbols for keycodes outside this range remained unchanged. The number of elements in the keysyms list must be a multiple of keysyms-per-keycode (or a -Length +Length error results). The first-keycode must be greater than or equal to min-keycode as returned in the connection setup (or a -Value +Value error results) and: first-keycode + (keysyms-length / keysyms-per-keycode) - 1 @@ -11321,7 +11321,7 @@ first-keycode + (keysyms-length / keysyms-per-keycode) - 1 must be less than or equal to max-keycode as returned in the connection setup (or a -Value +Value error results). KEYSYM number N (counting from zero) for keycode K has an index (counting from zero) of: @@ -11334,15 +11334,15 @@ in keysyms. The keysyms-per-keycode can be chosen arbitrarily by the client to be large enough to hold all desired symbols. A special KEYSYM value of -NoSymbol +NoSymbol should be used to fill in unused elements for individual keycodes. It is legal for -NoSymbol +NoSymbol to appear in nontrailing positions of the effective list for a keycode. This request generates a -MappingNotify +MappingNotify event. @@ -11406,7 +11406,7 @@ This request returns the symbols for the specified number of keycodes, starting with the specified keycode. The first-keycode must be greater than or equal to min-keycode as returned in the connection setup (or a -Value +Value error results), and: first-keycode + count - 1 @@ -11415,7 +11415,7 @@ first-keycode + count - 1 must be less than or equal to max-keycode as returned in the connection setup (or a -Value +Value error results). The number of elements in the keysyms list is: @@ -11434,7 +11434,7 @@ in keysyms. The keysyms-per-keycode value is chosen arbitrarily by the server to be large enough to report all requested symbols. A special KEYSYM value of -NoSymbol +NoSymbol is used to fill in unused elements for individual keycodes. @@ -11534,7 +11534,7 @@ The key-click-percent sets the volume for key clicks between 0 (off) and 100 (loud) inclusive, if possible. Setting to -1 restores the default. Other negative values generate a -Value +Value error. @@ -11542,14 +11542,14 @@ The bell-percent sets the base volume for the bell between 0 (off) and 100 (loud) inclusive, if possible. Setting to -1 restores the default. Other negative values generate a -Value +Value error. The bell-pitch sets the pitch (specified in Hz) of the bell, if possible. Setting to -1 restores the default. Other negative values generate a -Value +Value error. @@ -11557,7 +11557,7 @@ The bell-duration sets the duration of the bell (specified in milliseconds), if possible. Setting to -1 restores the default. Other negative values generate a -Value +Value error. @@ -11568,7 +11568,7 @@ then the state of all LEDs are changed, if possible. At most 32 LEDs, numbered from one, are supported. No standard interpretation of LEDs is defined. It is a -Match +Match error if an led is specified without an led-mode. @@ -11578,22 +11578,22 @@ If only auto-repeat-mode is specified, then the global auto-repeat mode for the entire keyboard is changed, if possible, without affecting the per-key settings. It is a -Match +Match error if a key is specified without an auto-repeat-mode. Each key has an individual mode of whether or not it should auto-repeat and a default setting for that mode. In addition, there is a global mode of whether auto-repeat should be enabled or not and a default setting for that mode. When the global mode is -On , +On, keys should obey their individual auto-repeat modes. When the global mode is -Off , +Off, no keys should auto-repeat. An auto-repeating key generates alternating -KeyPress +KeyPress and -KeyRelease +KeyRelease events. When a key is used as a modifier, it is desirable for the key not to auto-repeat, @@ -11651,8 +11651,8 @@ led-mask: CARD32 global-auto-repeat: -{ On , -Off } +{ On, +Off} @@ -11710,7 +11710,7 @@ Errors: This request rings the bell on the keyboard at a volume relative to the base volume for the keyboard, if possible. Percent can range from -100 to 100 inclusive (or a -Value +Value error results). The volume at which the bell is rung when percent is nonnegative is: @@ -11748,8 +11748,8 @@ base + [(base * percent) / 100] status: -{ Success , -Busy } +{ Success, +Busy} @@ -11770,9 +11770,9 @@ Errors: This request sets the mapping of the pointer. Elements of the list are indexed starting from one. The length of the list must be the same as -GetPointerMapping +GetPointerMapping would return (or a -Value +Value error results). The index is a core button number, and the element of the list defines the effective number. @@ -11781,20 +11781,20 @@ and the element of the list defines the effective number. A zero element disables a button. Elements are not restricted in value by the number of physical buttons, but no two elements can have the same nonzero value (or a -Value +Value error results). If any of the buttons to be altered are logically in the down state, the status reply is -Busy , +Busy, and the mapping is not changed. This request generates a -MappingNotify +MappingNotify event on a -Success +Success status. @@ -11880,7 +11880,7 @@ Acceleration only takes effect if the pointer moves more than threshold number of pixels at once and only applies to the amount beyond the threshold. Setting a value to -1 restores the default. Other negative values generate a -Value +Value error, as does a zero value for acceleration-denominator. @@ -11935,17 +11935,17 @@ This request returns the current acceleration and threshold for the pointer. prefer-blanking: -{ Yes , -No , -Default } +{ Yes, +No, +Default} allow-exposures: -{ Yes , -No , -Default } +{ Yes, +No, +Default} @@ -11966,7 +11966,7 @@ Errors: The timeout and interval are specified in seconds; setting a value to -1 restores the default. Other negative values generate a -Value +Value error. If the timeout value is zero, screen-saver is disabled (but an activated screen-saver is not deactivated). @@ -11985,9 +11985,9 @@ the screen is changed in a server-dependent fashion to avoid phosphor burn. Otherwise, the state of the screens does not change, and screen-saver is not activated. At the next keyboard or pointer input or at the next -ForceScreenSaver +ForceScreenSaver with mode -Reset , +Reset, screen-saver is deactivated, and all screen states are restored. @@ -12022,15 +12022,15 @@ timeout, interval: CARD16 prefer-blanking: -{ Yes , -No } +{ Yes, +No} allow-exposures: -{ Yes , -No } +{ Yes, +No} @@ -12055,8 +12055,8 @@ This request returns the current screen-saver control values. mode: -{ Activate , -Reset } +{ Activate, +Reset} @@ -12075,12 +12075,12 @@ Errors: If the mode is -Activate +Activate and screen-saver is currently deactivated, then screen-saver is activated (even if screen-saver has been disabled with a timeout value of zero). If the mode is -Reset +Reset and screen-saver is currently enabled, then screen-saver is deactivated (if it was activated), and the activation timer is reset to its initial state @@ -12099,8 +12099,8 @@ as if device input had just been received. mode: -{ Insert , -Delete } +{ Insert, +Delete} @@ -12113,7 +12113,7 @@ as if device input had just been received. Errors: -Access , +Access, Value @@ -12134,7 +12134,7 @@ method, or the server will refuse the connection. The client must reside on the same host as the server and/or have been granted permission by a server-dependent method to execute this request (or an -Access +Access error results). @@ -12147,7 +12147,7 @@ A server is not required to support these families and may support families not listed here. Use of an unsupported family, an improper address format, or an improper address length within a supported family results in a -Value +Value error. @@ -12219,8 +12219,8 @@ or public key encryption, are recommended. mode: -{ Enabled , -Disabled } +{ Enabled, +Disabled} @@ -12255,8 +12255,8 @@ Each HOST is padded to a multiple of four bytes. mode: -{ Enable , -Disable } +{ Enable, +Disable} @@ -12264,7 +12264,7 @@ Each HOST is padded to a multiple of four bytes. Errors: -Access , +Access, Value @@ -12282,7 +12282,7 @@ at connection setups. The client must reside on the same host as the server and/or have been granted permission by a server-dependent method to execute this request (or an -Access +Access error results). @@ -12298,9 +12298,9 @@ error results). mode: -{ Destroy , -RetainPermanent , -RetainTemporary } +{ Destroy, +RetainPermanent, +RetainTemporary} @@ -12321,7 +12321,7 @@ Errors: This request defines what will happen to the client's resources at connection close. A connection starts in -Destroy +Destroy mode. The meaning of the close-down mode is described in section 10. @@ -12358,19 +12358,19 @@ Errors: If a valid resource is specified, -KillClient +KillClient forces a close-down of the client that created the resource. If the client has already terminated in either -RetainPermanent +RetainPermanent or -RetainTemporary +RetainTemporary mode, all of the client's resources are destroyed (see section 10). If -AllTemporary +AllTemporary is specified, then the resources of all clients that have terminated in -RetainTemporary +RetainTemporary are destroyed. @@ -12400,31 +12400,31 @@ to begin on 64-bit boundaries. At connection close, all event selections made by the client are discarded. If the client has the pointer actively grabbed, an -UngrabPointer +UngrabPointer is performed. If the client has the keyboard actively grabbed, an -UngrabKeyboard +UngrabKeyboard is performed. All passive grabs by the client are released. If the client has the server grabbed, an -UngrabServer +UngrabServer is performed. All selections (see -SetSelectionOwner +SetSelectionOwner request) owned by the client are disowned. If close-down mode (see -SetCloseDownMode +SetCloseDownMode request) is -RetainPermanent +RetainPermanent or -RetainTemporary , +RetainTemporary, then all resources (including colormap entries) allocated by the client are marked as permanent or temporary, respectively (but this does not prevent other clients from explicitly destroying them). If the mode is -Destroy , +Destroy, all of the client's resources are destroyed. @@ -12434,7 +12434,7 @@ if the window is an inferior of a window created by the client, the save-set window is reparented to the closest ancestor such that the save-set window is not an inferior of a window created by the client. If the save-set window is unmapped, a -MapWindow +MapWindow request is performed on it (even if it was not an inferior of a window created by the client). The reparenting leaves unchanged the absolute coordinates @@ -12444,7 +12444,7 @@ After save-set processing, all windows created by the client are destroyed. For each nonwindow resource created by the client, the appropriate -Free +Free request is performed. All colors and colormap entries allocated by the client are freed. @@ -12453,27 +12453,27 @@ A server goes through a cycle of having no connections and having some connections. At every transition to the state of having no connections as a result of a connection closing with a -Destroy +Destroy close-down mode, the server resets its state as if it had just been started. This starts by destroying all lingering resources from clients that have terminated in -RetainPermanent +RetainPermanent or -RetainTemporary +RetainTemporary mode. It additionally includes deleting all but the predefined atom identifiers, deleting all properties on all root windows, resetting all device maps and attributes (key click, bell volume, acceleration), resetting the access control list, restoring the standard root tiles and cursors, restoring the default font path, and restoring the input focus to state -PointerRoot . +PointerRoot. Note that closing a connection with a close-down mode of -RetainPermanent +RetainPermanent or -RetainTemporary +RetainTemporary will not cause the server to reset. @@ -12526,9 +12526,9 @@ Client's selected pointer events on the event window owner-events -True +True if the client has -OwnerGrabButton +OwnerGrabButton selected on the event window, otherwise False @@ -12554,9 +12554,9 @@ selected on the event window, otherwise The grab is terminated automatically when the logical state of the pointer has all buttons released. -UngrabPointer +UngrabPointer and -ChangeActivePointerGrab +ChangeActivePointerGrab can both be used to modify the active grab. @@ -12642,9 +12642,9 @@ or when the pointer logically moves. The generation of these logical changes may lag the physical changes if device event processing is frozen. Note that -KeyPress +KeyPress and -KeyRelease +KeyRelease are generated for all keys, even those mapped to modifier bits. The source of the event is the window the pointer is in. The window the event is reported with respect to is called the event window. @@ -12668,7 +12668,7 @@ If the source window is an inferior of the event window, then child is set to the child of the event window that is an ancestor of (or is) the source window. Otherwise, it is set to -None . +None. The state component gives the logical state of the buttons and modifier keys just before the event. The detail component type varies with the event type: @@ -12713,41 +12713,41 @@ The detail component type varies with the event type: -MotionNotify +MotionNotify events are only generated when the motion begins and ends in the window. The granularity of motion events is not guaranteed, but a client selecting for motion events is guaranteed to get at least one event when the pointer moves and comes to rest. Selecting -PointerMotion +PointerMotion receives events independent of the state of the pointer buttons. By selecting some subset of -Button[1-5]Motion +Button[1-5]Motion instead, -MotionNotify +MotionNotify events will only be received when one or more of the specified buttons are pressed. By selecting -ButtonMotion , -MotionNotify +ButtonMotion, +MotionNotify events will be received only when at least one button is pressed. The events are always of type -MotionNotify , +MotionNotify, independent of the selection. If -PointerMotionHint +PointerMotionHint is selected, the server is free to send only one -MotionNotify +MotionNotify event (with detail -Hint ) +Hint) to the client for the event window until either the key or button state changes, the pointer leaves the event window, or the client issues a -QueryPointer +QueryPointer or -GetMotionEvents +GetMotionEvents request. @@ -12790,19 +12790,19 @@ request. mode: -{ Normal , -Grab , -Ungrab } +{ Normal, +Grab, +Ungrab} detail: -{ Ancestor , -Virtual , -Inferior , -Nonlinear , -NonlinearVirtual } +{ Ancestor, +Virtual, +Inferior, +Nonlinear, +NonlinearVirtual} @@ -12829,20 +12829,20 @@ request. If pointer motion or window hierarchy change causes the pointer to be in a different window than before, -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events are generated instead of a -MotionNotify +MotionNotify event. Only clients selecting -EnterWindow +EnterWindow on a window receive -EnterNotify +EnterNotify events, and only clients selecting -LeaveWindow +LeaveWindow receive -LeaveNotify +LeaveNotify events. The pointer position reported in the event is always the final position, not the initial position of the pointer. @@ -12855,52 +12855,52 @@ then event-x and event-y are the pointer coordinates relative to the event window's origin. Otherwise, event-x and event-y are zero. In a -LeaveNotify +LeaveNotify event, if a child of the event window contains the initial position of the pointer, then the child component is set to that child. Otherwise, it is -None . +None. For an -EnterNotify +EnterNotify event, if a child of the event window contains the final pointer position, then the child component is set to that child. Otherwise, it is -None . +None. If the event window is the focus window or an inferior of the focus window, then focus is -True . +True. Otherwise, focus is -False . +False. Normal pointer motion events have mode -Normal . +Normal. Pseudo-motion events when a grab activates have mode -Grab , +Grab, and pseudo-motion events when a grab deactivates have mode -Ungrab . +Ungrab. All -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events caused by a hierarchy change are generated after any hierarchy event caused by that change (that is, -UnmapNotify , -MapNotify , -ConfigureNotify , -GravityNotify , -CirculateNotify ), +UnmapNotify, +MapNotify, +ConfigureNotify, +GravityNotify, +CirculateNotify), but the ordering of -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events with respect to -FocusOut , -VisibilityNotify , +FocusOut, +VisibilityNotify, and -Expose +Expose events is not constrained. @@ -12915,25 +12915,25 @@ of B: -LeaveNotify +LeaveNotify with detail -Ancestor +Ancestor is generated on A. -LeaveNotify +LeaveNotify with detail -Virtual +Virtual is generated on each window between A and B exclusive (in that order). -EnterNotify +EnterNotify with detail -Inferior +Inferior is generated on B. @@ -12948,25 +12948,25 @@ of A: -LeaveNotify +LeaveNotify with detail -Inferior +Inferior is generated on A. -EnterNotify +EnterNotify with detail -Virtual +Virtual is generated on each window between A and B exclusive (in that order). -EnterNotify +EnterNotify with detail -Ancestor +Ancestor is generated on B. @@ -12980,33 +12980,33 @@ their least common ancestor: -LeaveNotify +LeaveNotify with detail -Nonlinear +Nonlinear is generated on A. -LeaveNotify +LeaveNotify with detail -NonlinearVirtual +NonlinearVirtual is generated on each window between A and C exclusive (in that order). -EnterNotify +EnterNotify with detail -NonlinearVirtual +NonlinearVirtual is generated on each window between C and B exclusive (in that order). -EnterNotify +EnterNotify with detail -Nonlinear +Nonlinear is generated on B. @@ -13019,36 +13019,36 @@ When the pointer moves from window A to window B on different screens: -LeaveNotify +LeaveNotify with detail -Nonlinear +Nonlinear is generated on A. If A is not a root window, -LeaveNotify +LeaveNotify with detail -NonlinearVirtual +NonlinearVirtual is generated on each window above A up to and including its root (in order). If B is not a root window, -EnterNotify +EnterNotify with detail -NonlinearVirtual +NonlinearVirtual is generated on each window from B's root down to but not including B (in order). -EnterNotify +EnterNotify with detail -Nonlinear +Nonlinear is generated on B. @@ -13057,7 +13057,7 @@ is generated on B. When a pointer grab activates (but after any initial warp into a confine-to window and before generating any actual -ButtonPress +ButtonPress event that activates the grab), G is the grab-window for the grab, and P is the window the pointer is in: @@ -13065,13 +13065,13 @@ G is the grab-window for the grab, and P is the window the pointer is in: -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events with mode -Grab +Grab are generated (as for -Normal +Normal above) as if the pointer were to suddenly warp from its current position in P to some position in G. However, the pointer does not warp, @@ -13083,7 +13083,7 @@ and final positions for the events. When a pointer grab deactivates (but after generating any actual -ButtonRelease +ButtonRelease event that deactivates the grab), G is the grab-window for the grab, and P is the window the pointer is in: @@ -13091,13 +13091,13 @@ the grab, and P is the window the pointer is in: -EnterNotify +EnterNotify and -LeaveNotify +LeaveNotify events with mode -Ungrab +Ungrab are generated (as for -Normal +Normal above) as if the pointer were to suddenly warp from some position in G to its current position in P. However, the pointer does not warp, @@ -13129,10 +13129,10 @@ and final positions for the events. mode: -{ Normal , -WhileGrabbed , -Grab , -Ungrab } +{ Normal, +WhileGrabbed, +Grab, +Ungrab} @@ -13161,40 +13161,40 @@ and final positions for the events. These events are generated when the input focus changes and are reported to clients selecting -FocusChange +FocusChange on the window. Events generated by -SetInputFocus +SetInputFocus when the keyboard is not grabbed have mode -Normal . +Normal. Events generated by -SetInputFocus +SetInputFocus when the keyboard is grabbed have mode -WhileGrabbed . +WhileGrabbed. Events generated when a keyboard grab activates have mode -Grab , +Grab, and events generated when a keyboard grab deactivates have mode -Ungrab . +Ungrab. All -FocusOut +FocusOut events caused by a window unmap are generated after any -UnmapNotify +UnmapNotify event, but the ordering of -FocusOut +FocusOut with respect to generated -EnterNotify , -LeaveNotify , -VisibilityNotify , +EnterNotify, +LeaveNotify, +VisibilityNotify, and -Expose +Expose events is not constrained. -Normal +Normal and -WhileGrabbed +WhileGrabbed events are generated as follows: @@ -13205,25 +13205,25 @@ and the pointer is in window P: -FocusOut +FocusOut with detail -Ancestor +Ancestor is generated on A. -FocusOut +FocusOut with detail -Virtual +Virtual is generated on each window between A and B exclusive (in order). -FocusIn +FocusIn with detail -Inferior +Inferior is generated on B. @@ -13231,9 +13231,9 @@ is generated on B. If P is an inferior of B but P is not A or an inferior of A or an ancestor of A, -FocusIn +FocusIn with detail -Pointer +Pointer is generated on each window below B down to and including P (in order). @@ -13250,33 +13250,33 @@ and the pointer is in window P: If P is an inferior of A but P is not an inferior of B or an ancestor of B, -FocusOut +FocusOut with detail -Pointer +Pointer is generated on each window from P up to but not including A (in order). -FocusOut +FocusOut with detail -Inferior +Inferior is generated on A. -FocusIn +FocusIn with detail -Virtual +Virtual is generated on each window between A and B exclusive (in order). -FocusIn +FocusIn with detail -Ancestor +Ancestor is generated on B. @@ -13291,50 +13291,50 @@ least common ancestor, and the pointer is in window P: If P is an inferior of A, -FocusOut +FocusOut with detail -Pointer +Pointer is generated on each window from P up to but not including A (in order). -FocusOut +FocusOut with detail -Nonlinear +Nonlinear is generated on A. -FocusOut +FocusOut with detail -NonlinearVirtual +NonlinearVirtual is generated on each window between A and C exclusive (in order). -FocusIn +FocusIn with detail -NonlinearVirtual +NonlinearVirtual is generated on each window between C and B exclusive (in order). -FocusIn +FocusIn with detail -Nonlinear +Nonlinear is generated on B. If P is an inferior of B, -FocusIn +FocusIn with detail -Pointer +Pointer is generated on each window below B down to and including P (in order). @@ -13350,53 +13350,53 @@ and the pointer is in window P: If P is an inferior of A, -FocusOut +FocusOut with detail -Pointer +Pointer is generated on each window from P up to but not including A (in order). -FocusOut +FocusOut with detail -Nonlinear +Nonlinear is generated on A. If A is not a root window, -FocusOut +FocusOut with detail -NonlinearVirtual +NonlinearVirtual is generated on each window above A up to and including its root (in order). If B is not a root window, -FocusIn +FocusIn with detail -NonlinearVirtual +NonlinearVirtual is generated on each window from B's root down to but not including B (in order). -FocusIn +FocusIn with detail -Nonlinear +Nonlinear is generated on B. If P is an inferior of B, -FocusIn +FocusIn with detail -Pointer +Pointer is generated on each window below B down to and including P (in order). @@ -13404,9 +13404,9 @@ is generated on each window below B down to and including P (in order). When the focus moves from window A to -PointerRoot +PointerRoot (or -None ) +None) and the pointer is in window P: @@ -13415,46 +13415,46 @@ and the pointer is in window P: If P is an inferior of A, -FocusOut +FocusOut with detail -Pointer +Pointer is generated on each window from P up to but not including A (in order). -FocusOut +FocusOut with detail -Nonlinear +Nonlinear is generated on A. If A is not a root window, -FocusOut +FocusOut with detail -NonlinearVirtual +NonlinearVirtual is generated on each window above A up to and including its root (in order). -FocusIn +FocusIn with detail -PointerRoot +PointerRoot (or -None ) +None) is generated on all root windows. If the new focus is -PointerRoot , -FocusIn +PointerRoot, +FocusIn with detail -Pointer +Pointer is generated on each window from P's root down to and including P (in order). @@ -13462,9 +13462,9 @@ is generated on each window from P's root down to and including P (in order). When the focus moves from -PointerRoot +PointerRoot (or -None ) +None) to window A and the pointer is in window P: @@ -13476,44 +13476,44 @@ If the old focus is PointerRoot, FocusOut with detail -Pointer +Pointer is generated on each window from P up to and including P's root (in order). -FocusOut +FocusOut with detail -PointerRoot +PointerRoot (or -None ) +None) is generated on all root windows. If A is not a root window, -FocusIn +FocusIn with detail -NonlinearVirtual +NonlinearVirtual is generated on each window from A's root down to but not including A (in order). -FocusIn +FocusIn with detail -Nonlinear +Nonlinear is generated on A. If P is an inferior of A, -FocusIn +FocusIn with detail -Pointer +Pointer is generated on each window below A down to and including P (in order). @@ -13521,9 +13521,9 @@ is generated on each window below A down to and including P (in order). When the focus moves from -PointerRoot +PointerRoot to -None +None (or vice versa) and the pointer is in window P: @@ -13532,39 +13532,39 @@ to If the old focus is PointerRoot, -FocusOut +FocusOut with detail -Pointer +Pointer is generated on each window from P up to and including P's root (in order). -FocusOut +FocusOut with detail -PointerRoot +PointerRoot (or -None ) +None) is generated on all root windows. -FocusIn +FocusIn with detail -None +None (or -PointerRoot ) +PointerRoot) is generated on all root windows. If the new focus is -PointerRoot , -FocusIn +PointerRoot, +FocusIn with detail -Pointer +Pointer is generated on each window from P's root down to and including P (in order). @@ -13573,7 +13573,7 @@ is generated on each window from P's root down to and including P (in order). When a keyboard grab activates (but before generating any actual -KeyPress +KeyPress event that activates the grab), G is the grab-window for the grab, and F is the current focus: @@ -13581,13 +13581,13 @@ and F is the current focus: -FocusIn +FocusIn and -FocusOut +FocusOut events with mode -Grab +Grab are generated (as for -Normal +Normal above) as if the focus were to change from F to G. @@ -13595,7 +13595,7 @@ above) as if the focus were to change from F to G. When a keyboard grab deactivates (but after generating any actual -KeyRelease +KeyRelease event that deactivates the grab), G is the grab-window for the grab, and F is the current focus: @@ -13603,13 +13603,13 @@ and F is the current focus: -FocusIn +FocusIn and -FocusOut +FocusOut events with mode -Ungrab +Ungrab are generated (as for -Normal +Normal above) as if the focus were to change from G to F. @@ -13635,13 +13635,13 @@ above) as if the focus were to change from G to F. The value is a bit vector as described in -QueryKeymap . +QueryKeymap. This event is reported to clients selecting -KeymapState +KeymapState on a window and is generated immediately after every -EnterNotify +EnterNotify and -FocusIn . +FocusIn. @@ -13678,19 +13678,19 @@ and This event is reported to clients selecting -Exposure +Exposure on the window. It is generated when no valid contents are available for regions of a window, and either the regions are visible, the regions are viewable and the server is (perhaps newly) maintaining backing store on the window, or the window is not viewable but the server is (perhaps newly) honoring window's backing-store attribute of -Always +Always or -WhenMapped . +WhenMapped. The regions are decomposed into an arbitrary set of rectangles, and an -Expose +Expose event is generated for each rectangle. @@ -13698,11 +13698,11 @@ For a given action causing exposure events, the set of events for a given window are guaranteed to be reported contiguously. If count is zero, then no more -Expose +Expose events for this window follow. If count is nonzero, then at least that many more -Expose +Expose events for this window follow (and possibly more). @@ -13711,38 +13711,38 @@ and specify the upper-left corner of a rectangle. The width and height specify the extent of the rectangle. -Expose +Expose events are never generated on -InputOnly +InputOnly windows. All -Expose +Expose events caused by a hierarchy change are generated after any hierarchy event caused by that change (for example, -UnmapNotify , -MapNotify , -ConfigureNotify , -GravityNotify , -CirculateNotify ). +UnmapNotify, +MapNotify, +ConfigureNotify, +GravityNotify, +CirculateNotify). All -Expose +Expose events on a given window are generated after any -VisibilityNotify +VisibilityNotify event on that window, but it is not required that all -Expose +Expose events on all windows be generated after all -Visibilitity +Visibilitity events on all windows. The ordering of -Expose +Expose events with respect to -FocusOut , -EnterNotify , +FocusOut, +EnterNotify, and -LeaveNotify +LeaveNotify events is not constrained. @@ -13794,11 +13794,11 @@ to an obscured or out-of-bounds source region. All of the regions exposed by a given graphics request are guaranteed to be reported contiguously. If count is zero then no more -GraphicsExposure +GraphicsExposure events for this window follow. If count is nonzero, then at least that many more -GraphicsExposure +GraphicsExposure events for this window follow (and possibly more). @@ -13810,9 +13810,9 @@ The width and height specify the extent of the rectangle. The major and minor opcodes identify the graphics request used. For the core protocol, major-opcode is always -CopyArea +CopyArea or -CopyPlane , +CopyPlane, and minor-opcode is always zero. @@ -13851,7 +13851,7 @@ This event is reported to a client using a graphics context with graphics-exposures selected and is generated when a graphics request that might produce -GraphicsExposure +GraphicsExposure events does not produce any. The drawable specifies the destination used for the graphics request. @@ -13859,9 +13859,9 @@ The drawable specifies the destination used for the graphics request. The major and minor opcodes identify the graphics request used. For the core protocol, major-opcode is always -CopyArea +CopyArea or -CopyPlane , +CopyPlane, and the minor-opcode is always zero. @@ -13882,9 +13882,9 @@ and the minor-opcode is always zero. state: -{ Unobscured , -PartiallyObscured , -FullyObscured } +{ Unobscured, +PartiallyObscured, +FullyObscured} @@ -13895,61 +13895,61 @@ and the minor-opcode is always zero. This event is reported to clients selecting -VisibilityChange +VisibilityChange on the window. In the following, the state of the window is calculated ignoring all of the window's subwindows. When a window changes state from partially or fully obscured or not viewable to viewable and completely unobscured, an event with -Unobscured +Unobscured is generated. When a window changes state from viewable and completely unobscured, from viewable and completely obscured, or from not viewable, to viewable and partially obscured, an event with -PartiallyObscured +PartiallyObscured is generated. When a window changes state from viewable and completely unobscured, from viewable and partially obscured, or from not viewable to viewable and fully obscured, an event with -FullyObscured +FullyObscured is generated. -VisibilityNotify +VisibilityNotify events are never generated on -InputOnly +InputOnly windows. All -VisibilityNotify +VisibilityNotify events caused by a hierarchy change are generated after any hierarchy event caused by that change (for example, -UnmapNotify , -MapNotify , -ConfigureNotify , -GravityNotify , -CirculateNotify ). +UnmapNotify, +MapNotify, +ConfigureNotify, +GravityNotify, +CirculateNotify). Any -VisibilityNotify +VisibilityNotify event on a given window is generated before any -Expose +Expose events on that window, but it is not required that all -VisibilityNotify +VisibilityNotify events on all windows be generated before all -Expose +Expose events on all windows. The ordering of -VisibilityNotify +VisibilityNotify events with respect to -FocusOut , -EnterNotify , +FocusOut, +EnterNotify, and -LeaveNotify +LeaveNotify events is not constrained. @@ -13990,11 +13990,11 @@ events is not constrained. This event is reported to clients selecting -SubstructureNotify +SubstructureNotify on the parent and is generated when the window is created. The arguments are as in the -CreateWindow +CreateWindow request. @@ -14020,9 +14020,9 @@ request. This event is reported to clients selecting -StructureNotify +StructureNotify on the window and to clients selecting -SubstructureNotify +SubstructureNotify on the parent. It is generated when the window is destroyed. The event is the window on which the event was generated, @@ -14030,9 +14030,9 @@ and the window is the window that is destroyed. The ordering of the -DestroyNotify +DestroyNotify events is such that for any given window, -DestroyNotify +DestroyNotify is generated on all inferiors of the window before being generated on the window itself. The ordering among siblings and across subhierarchies is not @@ -14066,18 +14066,18 @@ otherwise constrained. This event is reported to clients selecting -StructureNotify +StructureNotify on the window and to clients selecting -SubstructureNotify +SubstructureNotify on the parent. It is generated when the window changes state from mapped to unmapped. The event is the window on which the event was generated, and the window is the window that is unmapped. The from-configure flag is -True +True if the event was generated as a result of the window's parent being resized when the window itself had a win-gravity of -Unmap . +Unmap. @@ -14107,9 +14107,9 @@ when the window itself had a win-gravity of This event is reported to clients selecting -StructureNotify +StructureNotify on the window and to clients selecting -SubstructureNotify +SubstructureNotify on the parent. It is generated when the window changes state from unmapped to mapped. The event is the window on which the event was generated, @@ -14139,11 +14139,11 @@ The override-redirect flag is from the window's attribute. This event is reported to the client selecting -SubstructureRedirect +SubstructureRedirect on the parent and is generated when a -MapWindow +MapWindow request is issued on an unmapped window with an override-redirect attribute of -False . +False. @@ -14178,9 +14178,9 @@ request is issued on an unmapped window with an override-redirect attribute of This event is reported to clients selecting -SubstructureNotify +SubstructureNotify on either the old or the new parent and to clients selecting -StructureNotify +StructureNotify on the window. It is generated when the window is reparented. The event is the window on which the event was generated. @@ -14234,12 +14234,12 @@ The override-redirect flag is from the window's attribute. This event is reported to clients selecting -StructureNotify +StructureNotify on the window and to clients selecting -SubstructureNotify +SubstructureNotify on the parent. It is generated when a -ConfigureWindow +ConfigureWindow request actually changes the state of the window. The event is the window on which the event was generated, and the window is the window that is changed. @@ -14247,7 +14247,7 @@ The x and y coordinates are relative to the new parent's origin and specify the position of the upper-left outer corner of the window. The width and height specify the inside size, not including the border. If above-sibling is -None , +None, then the window is on the bottom of the stack with respect to siblings. Otherwise, the window is immediately on top of the specified sibling. The override-redirect flag is from the window's attribute. @@ -14280,9 +14280,9 @@ The override-redirect flag is from the window's attribute. This event is reported to clients selecting -SubstructureNotify +SubstructureNotify on the parent and to clients selecting -StructureNotify +StructureNotify on the window. It is generated when a window is moved because of a change in size of the parent. @@ -14319,9 +14319,9 @@ and specify the position of the upper-left outer corner of the window. This event is reported to the client selecting -ResizeRedirect +ResizeRedirect on the window and is generated when a -ConfigureWindow +ConfigureWindow request by some other client on the window attempts to change the size of the window. The width and height are the requested inside size, not including the border. @@ -14360,11 +14360,11 @@ The width and height are the requested inside size, not including the border. stack-mode: -{ Above , -Below , -TopIf , -BottomIf , -Opposite } +{ Above, +Below, +TopIf, +BottomIf, +Opposite} @@ -14380,9 +14380,9 @@ The width and height are the requested inside size, not including the border. This event is reported to the client selecting -SubstructureRedirect +SubstructureRedirect on the parent and is generated when a -ConfigureWindow +ConfigureWindow request is issued on the window by some other client. The value-mask indicates which components were specified in the request. The value-mask and the corresponding values are reported as given @@ -14390,9 +14390,9 @@ in the request. The remaining values are filled in from the current geometry of the window, except in the case of sibling and stack-mode, which are reported as -None +None and -Above +Above (respectively) if not given in the request. @@ -14413,8 +14413,8 @@ and place: -{ Top , -Bottom } +{ Top, +Bottom} @@ -14425,17 +14425,17 @@ and This event is reported to clients selecting -StructureNotify +StructureNotify on the window and to clients selecting -SubstructureNotify +SubstructureNotify on the parent. It is generated when the window is actually restacked from a -CirculateWindow +CirculateWindow request. The event is the window on which the event was generated, and the window is the window that is restacked. If place is -Top , +Top, the window is now on top of all siblings. Otherwise, it is below all siblings. @@ -14457,8 +14457,8 @@ Otherwise, it is below all siblings. place: -{ Top , -Bottom } +{ Top, +Bottom} @@ -14469,9 +14469,9 @@ Otherwise, it is below all siblings. This event is reported to the client selecting -SubstructureRedirect +SubstructureRedirect on the parent and is generated when a -CirculateWindow +CirculateWindow request is issued on the parent and a window actually needs to be restacked. The window specifies the window to be restacked, and the place specifies what the new position in the stacking order should be. @@ -14499,8 +14499,8 @@ and the place specifies what the new position in the stacking order should be. state: -{ NewValue , -Deleted } +{ NewValue, +Deleted} @@ -14516,26 +14516,26 @@ and the place specifies what the new position in the stacking order should be. This event is reported to clients selecting -PropertyChange +PropertyChange on the window and is generated with state -NewValue +NewValue when a property of the window is changed using -ChangeProperty +ChangeProperty or -RotateProperties , +RotateProperties, even when adding zero-length data using -ChangeProperty +ChangeProperty and when replacing all or part of a property with identical data using -ChangeProperty +ChangeProperty or -RotateProperties . +RotateProperties. It is generated with state -Deleted +Deleted when a property of the window is deleted using request -DeleteProperty +DeleteProperty or -GetProperty . +GetProperty. The timestamp indicates the server time when the property was changed. @@ -14572,10 +14572,10 @@ The timestamp indicates the server time when the property was changed. This event is reported to the current owner of a selection and is generated when a new owner is being defined by means of -SetSelectionOwner . +SetSelectionOwner. The timestamp is the last-change time recorded for the selection. The owner argument is the window that was specified by the current owner in its -SetSelectionOwner +SetSelectionOwner request. @@ -14629,19 +14629,19 @@ request. This event is reported to the owner of a selection and is generated when a client issues a -ConvertSelection +ConvertSelection request. The owner argument is the window that was specified in the -SetSelectionOwner +SetSelectionOwner request. The remaining arguments are as in the -ConvertSelection +ConvertSelection request. The owner should convert the selection based on the specified target type and send a -SelectionNotify +SelectionNotify back to the requestor. A complete specification for using selections is given in the X.Org standard Inter-Client Communication Conventions Manual. @@ -14686,15 +14686,15 @@ standard Inter-Client Communication Conventions Manual This event is generated by the server in response to a -ConvertSelection +ConvertSelection request when there is no owner for the selection. When there is an owner, it should be generated by the owner using -SendEvent . +SendEvent. The owner of a selection should send this event to a requestor either when a selection has been converted and stored as a property or when a selection conversion could not be performed (indicated with property -None ). +None). @@ -14725,8 +14725,8 @@ or when a selection conversion could not be performed (indicated with property state: -{ Installed , -Uninstalled } +{ Installed, +Uninstalled} @@ -14737,13 +14737,13 @@ or when a selection conversion could not be performed (indicated with property This event is reported to clients selecting -ColormapChange +ColormapChange on the window. It is generated with value -True +True for new when the colormap attribute of the window is changed and is generated with value -False +False for new when the colormap of a window is installed or uninstalled. In either case, the state indicates whether the colormap is currently installed. @@ -14761,9 +14761,9 @@ the state indicates whether the colormap is currently installed. request: -{ Modifier , -Keyboard , -Pointer } +{ Modifier, +Keyboard, +Pointer} @@ -14781,18 +14781,18 @@ the state indicates whether the colormap is currently installed. This event is sent to all clients. There is no mechanism to express disinterest in this event. The detail indicates the kind of change that occurred: -Modifiers +Modifiers for a successful -SetModifierMapping , -Keyboard +SetModifierMapping, +Keyboard for a successful -ChangeKeyboardMapping , +ChangeKeyboardMapping, and -Pointer +Pointer for a successful -SetPointerMapping . +SetPointerMapping. If the detail is -Keyboard , +Keyboard, then first-keycode and count indicate the range of altered keycodes. @@ -14833,7 +14833,7 @@ then first-keycode and count indicate the range of altered keycodes. This event is only generated by clients using -SendEvent . +SendEvent. The type specifies how the data is to be interpreted by the receiving client; the server places no interpretation on the type or the data. The format specifies whether the data should be viewed as a list of 8-bit,