Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1013

X Window System Protocol, version 11: Alpha update April 1987

Pages: 101
Unclassified
Part 2 of 3 – Pages 30 to 64
First   Prev   Next

ToP   noToC   RFC1013 - Page 30   prevText
           Changing the colormap of a window (i.e., defining a new map,
           not changing the contents of the existing map) generates a
           ColormapNorify event.  Changing the colormap os a visible
           window may have no immediate effect on the screen; see
           InstallColormap.

           Changing the cursor of a root window to None restores the
           default cursor.

           The order in which attributes are verified and altered is
           server dependent. If an error is generated, a subset of
           the attributes may have been altered.

GetWindowAttributes
           window: WINDOW
       =>
           visual: VISUALID
           class: {InputOutput, InputOnly}
           bit-gravity: BITGRAVITY
           win-gravity: WINGRAVITY
           backing-store: {NotUseful, WhenMapped, Always}
           backing-bit-planes: CARD32
           backing-pixel: CARD32
           save-under: BOOL
           colormap: COLORMAP or None
           map-is-installed: BOOL
           map-state: {Unmapped, Unviewable, Viewable}
           all-event-masks, your-event-mask: SETofEVENT
           do-not-propagate-mask: SETofDEVICEEVENT
           override-redirect: BOOL

           Errors: Window

           Returns current attributes of the window.  All-event-masks
           is the inclusive-OR of all event masks selected on the
           window by clients.  Your-event-mask is the event mask
           selected by the querying client.

DestroyWindow
           window: WINDOW

           Errors: Window

           If the argument window is mapped, an UnmapWindow request is
           performed automatically.  The window and all inferiors are
           then destroyed, and a DestroyNotify event is generated for
           each window, in order from the argument window downwards,
           with unspecified order among siblings at each level.

           Normal exposure processing on formerly obscured windows is
           performed.
ToP   noToC   RFC1013 - Page 31
           If the window is a root window, this request has no effect.

DestroySubwindows
           window: WINDOW

           Errors: Window

           Performs a DestroyWindow on all children of the window, in
           bottom to top stacking order.

ChangeSaveSet
           window: WINDOW
           mode: {Insert, Delete}

           Errors: Window, Match, Value

           Adds or removes the specified window from the client's
           "save-set".  The window must have been created by some other
           client (else a Match error).  The use of the save-set is
           described in Section 11.

           Windows are removed automatically from the save-set by the
           server when they are destroyed.

ReparentWindow
           window, parent: WINDOW
           x, y: INT16

           Errors: Window, Match

           If the window is mapped, an 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.  The x and y coordinates
           are relative to the parent's origin, and specify the new
           position of the upper left outer corner of the window.  The
           window is placed on top in the stacking order with respect
           to siblings.  A ReparentNotify event is then generated.  The
           override-redirect attribute of the window is passed on in
           this event; a value of True indicates that a window manager
           should not tamper with this window.  Finally, if the window
           was originally mapped, a MapWindow request is performed
           automatically.

           Normal exposure processing on formerly obscured windows is
           performed. The server might not generate exposure events for
           regions from the initial unmap that are immediately obscured
           by the final map.

           A Match error is generated if the new parent is not on the
           same screen as the old parent, or if the new parent is the
ToP   noToC   RFC1013 - Page 32
           window itself or an inferior of the window, or if the window
           has a ParentRelative background and the new parent is not
           the same depth as the window.

MapWindow
           window: WINDOW

           Errors: Window

           If the window is already mapped, this request has no effect.

           If the override-redirect attribute of the window is False and
           some other client has selected SubstructureRedirect on the
           parent, then a MapRequest event is generated, but the window
           remains unmapped. Otherwise, the window is mapped and a
           MapNotify event is generated.

           If the window is now viewable and its contents had been
           discarded, then the window is tiled with its background (if
           no background is defined the existing screen contents are not
           altered) and one or more exposure events are generated.  If a
           backing-store has been maintained while the window was
           unmapped, no exposure events are generated. If a
           backing-store will now be maintained, a full-window exposure
           is always generated; otherwise only visible regions may be
           reported. Similar tiling and exposure take place for any
           newly viewable inferiors.

MapSubwindows
           window: WINDOW

           Errors: Window

           Performs a MapWindow request on all unmapped children of the
           window, in top to bottom stacking order.

UnmapWindow
           window: WINDOW

           Errors: Window

           If the window is already unmapped, this request has no
           effect. Otherwise, the window is unmapped and an UnmapNotify
           event is generated.  Normal exposure processing on formerly
           obscured windows is performed.

UnmapSubwindows
           window: WINDOW

           Errors: Window
ToP   noToC   RFC1013 - Page 33
           Performs an UnmapWindow request on all mapped children of the
           window, in bottom to top stacking order.

ConfigureWindow
           window: WINDOW
           value-mask: BITMASK
           value-list: LISTofVALUE

           Errors: Window, Match, Value

           Changes the configuration of the window.  The value-mask and
           value-list specify which values are to be given.  The
           possible values are:

               x: INT16
               y: INT16
               width: CARD16
               height: CARD16
               border-width: CARD16
               sibling: WINDOW
               stack-mode: {Above, Below, TopIf, BottomIf, Opposite}

           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 non-zero.  It is a
           Match error to attempt to make the border-width of an
           InputOnly window non-zero.

           If the override-redirect attribute of the window is False
           and some other client has selected SubstructureRedirect on
           the parent, then a ConfigureRequest event is generated, and
           no further processing is performed.  Otherwise, the following
           is performed.

           If some other client has selected ResizeRedirect on the
           window and the width or height of the window is being
           changed, then a ResizeRequest event is generated, and the
           current width and height are used instead in the following.

           The geometry of the window is changed as specified and the
           window is restacked among siblings as described below, and a
           ConfigureNotify event is generated.  If the width or height
           of the window has actually changed, then children of the
           window are affected as described below.

           Exposure processing is performed on formerly obscured
           windows.

           Changing the width or height of the window causes its
           contents to be moved or lost, depending on the bit-gravity of
ToP   noToC   RFC1013 - Page 34
           the window, and causes children to be reconfigured, depending
           on their win-gravity.  For a change of width and height of W
           and H, we define the [x, y] pairs:

               NorthWest: [0, 0]
               North: [W/2, 0]
               NorthEast: [W, 0]
               West: [0, H/2]
               Center: [W/2, H/2]
               East: [W, H/2]
               SouthWest: [0, H]
               South: [W/2, H]
               SouthEast: [W, H]

           When a window with one of these bit-gravities is resized, the
           corresponding pair defines the change in position of each
           pixel in the window.  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.  When a window is so repositioned,
           a GravityNotify event is generated.

           A gravity of 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 in
           position of [X, Y], 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 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 indicates that the window contents
           are always discarded after a size change; the window is tiled
           with its background (if no background is defined, the
           existing screen contents are not altered) and one or more
           exposure events are generated.  A server may also ignore the
           specified bit-gravity and use Forget instead.

           A win-gravity of Unmap is like NorthWest, but the child is
           also unmapped when the parent is resized, and an UnmapNotify
           event is generated.

           If a sibling and a stack-mode is specified, the window is
           restacked as follows:

               Above:  window is placed just above sibling
               Below:  window is placed just below sibling
               TopIf:  if sibling occludes window, then window is placed
                       at the top of the stack
               BottomIf:  if window occludes sibling, then window is
ToP   noToC   RFC1013 - Page 35
                          placed at the bottom of the stack
               Opposite:  if sibling occludes window, then window is
                          placed at the top of the stack, else if window
                          occludes sibling, then window is placed at the
                          bottom of the stack

           If a stack-mode is specified but no sibling is specified, the
           window is restacked as follows:

               Above:  window is placed at the top of the stack
               Below:  window is placed at the bottom of the stack
               TopIf:  if any sibling occludes window, then window is
                       placed at the top of the stack
               BottomIf: if window occludes any sibling, then window is
                         placed at the bottom of the stack
               Opposite: if any sibling occludes window, then window is
                         placed at the top of the stack, else if window
                         occludes any sibling, then window is placed at
                         the bottom of the stack

           It is a Match error if a sibling is specified without a
           stack-mode, or if the window is not actually a sibling.

           Note that the computations for BottomIf, TopIf, and Opposite
           are performed with respect to the window's final geometry
           (as controlled by the other arguments to the request), not
           its initial geometry.

CirculateWindow
           window: WINDOW
           direction: {RaiseLowest, LowerHighest}

           Errors: Window, Value

           If some other client has selected SubstructureRedirect on the
           window, then a CirculateRequest event is generated, and no
           further processing is performed.  Otherwise, the following is
           performed, and then a CirculateNotify event is generated if
           the window is actually restacked.

           For RaiseLowest, raises the lowest mapped child (if any) that
           is occluded by another child to the top of the stack.  For
           LowerHighest, 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.

GetGeometry
           drawable: DRAWABLE
       =>
           root: WINDOW
           depth: CARD8
ToP   noToC   RFC1013 - Page 36
           x, y: INT16
           width, height, border-width: CARD16

           Errors: Drawable

           Returns the root and (current) geometry of the drawable.
           Depth is the number of bits per pixel for the object.
           X, y, and border-width will always be zero for pixmaps.
           For a window, the x and y coordinates specify the upper
           left outer corner of the window relative to its parent's
           origin, and the width and height specify the inside size
           (not including the border).

           It is legal to pass an InputOnly window as a drawable to
           this request.

QueryTree
           window: WINDOW
       =>
           root: WINDOW
           parent: WINDOW or None
           children: LISTofWINDOW

           Errors: Window

           Returns the root, the parent, and children of the window.
           The children are listed in bottom-to-top stacking order.

InternAtom
           name: STRING8
           only-if-exists: BOOL
       =>
           atom: ATOM or None

           Errors: Value, Alloc

           Returns the atom for the given name.  If only-if-exists is
           False, then the atom is created if it does not exist.  The
           string should use the ASCII encoding, and upper/lower case
           matters.

           The lifetime of an atom is not tied to the interning client.
           Atoms remained defined until server reset (see Section 11).

GetAtomName
           atom: ATOM
       =>
           name: STRING8

           Errors: Atom
ToP   noToC   RFC1013 - Page 37
           Returns the name for the given atom.

ChangeProperty
           window: WINDOW
           property, type: ATOM
           format: {8, 16, 32}
           mode: {Replace, Prepend, Append}
           data: LISTofINT8 or LISTofINT16 or LISTofINT32

           Errors: Window, Atom, Value, Match, Alloc

           Alters the property for the specified window.  The type is
           uninterpreted by the server.  The format specifies whether
           the data should be viewed as a list of 8-bit, 16-bit, or
           32-bit quantities, so that the server can correctly
           byte-swap as necessary.

           If mode is Replace, the previous property value is discarded.
           If the mode is Prepend or Append, then the type and format
           must match the existing property value (else a Match error);
           if the property is undefined, it is treated as defined with
           the correct type and format with zero-length data.  For
           Prepend, the data is tacked on to the beginning of the
           existing data, and for Append it is tacked on to the
           end of the existing data.

           Generates a PropertyNotify event on the window.

           The lifetime of a property is not tied to the storing client.
           Properties remain until explicitly deleted, or the window is
           destroyed, or until server reset (see Section 11).

           The maximum size of a property is server dependent.

DeleteProperty
           window: WINDOW
           property: ATOM

           Errors: Window, Atom

           Deletes the property from the specified window if the
           property exists. Generates a PropertyNotify event on the
           window unless the property does not exist.

GetProperty
           window: WINDOW
           property: ATOM
           type: ATOM or AnyPropertyType
           long-offset, long-length: CARD32
           delete: BOOL
       =>
ToP   noToC   RFC1013 - Page 38
           type: ATOM
           format: {8, 16, 32}
           bytes-after: CARD32
           value: LISTofINT8 or LISTofINT16 or LISTofINT32

           Errors: Window, Atom, Property, Match, Value

           If the specified property does not exist for the specifed
           window, a Property error is generated.  Otherwise, if type
           AnyPropertyType is specified, (part of) the property is
           returned regardless of its type; if a type is specified,
           (part of) the property is returned only if its type equals
           the specified type (else a Match error).  The actual type
           and format of the property are returned.

           Define the following values:
                   N = actual length of the stored property in bytes
                       (even if the format is 16 or 32)
                   I = 4 * long-offset
                   T = N - I
                   L = MINIMUM(T, 4 * long-length)
                   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.  It is a
           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 and bytes-after is zero, the property is
           also deleted from the window and a PropertyNotify event is
           generated on the window.

RotateProperties
           window: WINDOW
           delta: INT8
           properties: LISTofATOM

           Errors: Window, Atom, Match

           If the property names in the list are viewed as being
           numbered starting from zero, and there are N property names
           in the list, then the value associated with property name I
           becomes the value associated with property name (I + delta)
           mod N, for all I from zero to N - 1.  The effect is to rotate
           the states by delta places around the virtual ring of
           property names (right for positive delta, left for negative
           delta).

           A PropertyNotify event is generated for each property, in the
           order listed.
ToP   noToC   RFC1013 - Page 39
           If an atom occurs more than once in the list or no property
           with that name is defined for the window, a Match error is
           generated.  If an Atom or Match error is generated, no
           properties are changed.

ListProperties
           window: WINDOW
       =>
           atoms: LISTofATOM

           Errors: Window

           Returns the atoms of properties currently defined on the
           window.

SetSelectionOwner
           selection: ATOM
           owner: WINDOW or None
           time: TIMESTAMP or CurrentTime

           Error: Atom, Window

           Changes the owner and last-change time of the specifed
           selection.  The request has no effect if the specified time
           is earlier 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 replaced by the current server time.
           If the new owner is not the same as the current owner of the
           selection, and the current owner is a window, then the
           current owner is sent a SelectClear event.

           If the owner of a selection is a window, and the window is
           later destroyed, the owner of the selection automatically
           reverts to None, but the last-change time is not affected.

           The selection atom is uninterpreted by the server.

           Selections are global to the server.

GetSelectionOwner
           selection: ATOM
       =>
           owner: WINDOW or None

           Errors: Atom

           Returns the current owner of the specified selection, if any.

ConvertSelection
           selection, target: ATOM
ToP   noToC   RFC1013 - Page 40
           property: ATOM or None
           requestor: WINDOW
           time: TIMESTAMP or CurrentTime

           Error: Atom, Window

           If the specified selection is owned by a window, the server
           sends a SelectionRequest event to the owner.  If no owner for
           the specified selection exists, the server generates a
           SelectionNotify event to the requestor with property None.
           The arguments are passed on unchanged in either event.

SendEvent
           destination: WINDOW or PointerWindow or InputFocus
           propagate: BOOL
           event-mask: SETofEVENT
           event: <normal-event-format>

           Errors: Window, Value

           If PointerWindow is specified, destination is replaced with
           the window that the pointer is in.  If InputFocus is
           specified, then if the focus window contains the pointer,
           destination is replaced with the window that the pointer is
           in, and otherwise destination is replaced with the focus
           window.

           If propagate is False, then the event is sent to every client
           selecting on destination any of the event types in
           event-mask.

           If propagate is True and no clients have selected on
           destination any of the event types in event-mask, then
           destination is replaced with the closest ancestor of
           destination for which some client has selected a 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 was
           originally specified sent to any clients. Otherwise, the
           event is reported to every client selecting on the final
           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, so that the server can
           correctly byte swap the contents as necessary.  The
           contents of the event are otherwise unaltered and unchecked
           by the server except to force on the most significant bit
           of the event code.
ToP   noToC   RFC1013 - Page 41
           Active grabs are ignored for this request.

GrabPointer
           grab-window: WINDOW
           owner-events: BOOL
           event-mask: SETofPOINTEREVENT
           pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
           confine-to: WINDOW or None
           cursor: CURSOR or None
           time: TIMESTAMP or CurrentTime
       =>
           status: {Success, AlreadyGrabbed, Frozen, InvalidTime,
                    NotViewable}

           Errors: Cursor, Window, Value

           Actively grabs control of the pointer.  Further pointer
           events are only reported to the grabbing client.  The
           request overrides any active pointer grab by this client.

           Event-mask is always augmented to include ButtonPress and
           ButtonRelease.  If owner-events is 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, then if 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 only reported if selected by
           event-mask.  For either value of owner-events, unreported
           events are simply discarded.

           Pointer-mode controls further processing of pointer events,
           and keyboard-mode controls further processing of keyboard
           events.  If the mode is Asynchronous, event processing
           continues normally; if the device is currently frozen by
           this client, then processing of events for the device is
           resumed.  If the mode is Synchronous, the device (as seen
           via the protocol) appears to freeze, and no further events
           for that device are generated by the server until the
           grabbing client issues a releasing AllowEvents request.
           Actual device changes are not lost while the device is
           frozen; they are simply queued for later processing.

           If a cursor is specified, then it is displayed regardless
           of what window the pointer is in.  If no cursor is
           specified, then when the pointer is in grab-window or one
           of its subwindows, the normal cursor for that window is
           displayed, and otherwise the cursor for grab-window is
           displayed.
ToP   noToC   RFC1013 - Page 42
           If a confine-to window is specified, then the pointer
           will be restricted to stay contained in that window.
           The confine-to  window need have no relationship to the
           grab-window.  If the pointer is not initially in the
           confine-to window, then it is warped automatically to
           the closest edge (and enter/leave events generated
           normally) just  before the grab activates.  If the
           confine-to window is subsequently reconfigured, the
           pointer will be warped automatically as necessary to keep
           it contained in the window.

           This request generates EnterNotify and LeaveNotify events.

           The request fails with status AlreadyGrabbed if the
           pointer is actively grabbed by some other client.  The
           request fails with status Frozen if the pointer is frozen
           by an active grab of another client.  The request fails
           with status NotViewable if grab-window or
           confine-to window is not viewable.  The request fails with
           status 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 replaced by the
           current server time.

UngrabPointer
           time: TIMESTAMP or CurrentTime

           Releases the pointer if this client has it actively
           grabbed (from either GrabPointer or 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 and LeaveNotify events.

           An UngrabPointer is performed automatically if the event
           window or confine-to window for an active pointer grab
           becomes not viewable.

GrabButton
           modifiers: SETofKEYMASK or AnyModifier
           button: BUTTON or AnyButton
           grab-window: WINDOW
           owner-events: BOOL
           event-mask: SETofPOINTEREVENT
           pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
           confine-to: WINDOW or None
           cursor: CURSOR or None
ToP   noToC   RFC1013 - Page 43
           Errors: Cursor, Window, Value, Access

           This request establishes a passive grab.  In the future,
           if the specified button is pressed when the specified
           modifier keys are down (and no other buttons or modifier
           keys are down), and grab-window contains the pointer,
           and the confine-to window (if any) is viewable, and these
           constraints are not satisfied for any ancestor, then the
           pointer is actively grabbed as described in GrabPointer,
           the last-pointer-grab time is set to the time at which
           the button was pressed (as transmitted in the ButtonPress
           event), and the ButtonPress event is reported.  The
           interpretation of the remaining arguments is as for
           GrabPointer.  The active grab is terminated automatically
           when all buttons are released (independent of the state
           of modifier keys).

           A modifiers of AnyModifier is equivalent to issuing the
           request for all possible modifier combinations.  A
           button of AnyButton is equivalent to issuing the request
           for all possible buttons.

           An Access error is generated if some other client has
           already issued a GrabButton with the same button/key
           combination on the same window. When using AnyModifier
           or AnyButton, the request fails completely (no grabs are
           established) if there is a combination.  The request has
           no effect on an active grab.

UngrabButton
           modifiers: SETofKEYMASK or AnyModifier
           button: BUTTON or AnyButton
           grab-window: WINDOW

           Errors: Window

           Releases the passive button/key combination on the
           specified window if it was grabbed by this client. A
           modifiers of AnyModifier is equivalent to issuing the
           request for all possible modifier combinations.  A
           button of AnyButton is equivalent to issuing the request
           for all possible buttons. Has no effect on an active
           grab.

ChangeActivePointerGrab
           event-mask: SETofPOINTEREVENT
           cursor: CURSOR or None
           time: TIMESTAMP or CurrentTime

           Errors: Cursor
ToP   noToC   RFC1013 - Page 44
           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 as in GrabPointer.  The
           event-mask is always augmented to include ButtonPress
           and ButtonRelease.  Has no effect on the passive
           parameters of a GrabButton.

GrabKeyboard
           grab-window: WINDOW
           owner-events: BOOL
           pointer-mode, keyboard-mode: {Synchronous, Asynchronous}
           time: TIMESTAMP or CurrentTime
       =>
           status: {Success, AlreadyGrabbed, Frozen, InvalidTime,
                    NotViewable}

           Errors: Window, Value

           Actively grabs control of the keyboard.  Further key
           events are reported only to the grabbing client.  The
           request overrides any active keyboard grab by this
           client.

           If owner-events is False, all generated key events are
           reported with respect to grab-window.  If owner-events is
           True, then 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 and KeyRelease events are
           always reported, independent of any event selection made
           by the client.

           Pointer-mode controls further processing of pointer
           events, and keyboard-mode controls further processing of
           keyboard events.  If the mode is Asynchronous, event
           processing continues normally; if the device is currently
           frozen by this client, then processing of events for the
           device is resumed.  If the mode is Synchronous, the
           device (as seen via the protocol) appears to freeze, and
           no further events for that device are generated by the
           server until the grabbing client issues a releasing
           AllowEvents request.  Actual device changes are not lost
           while the device is frozen; they are simply queued for
           later processing.

           This request generates FocusIn and FocusOut events.

           The request fails with status AlreadyGrabbed if the
           keyboard is actively grabbed by some other client.  The
ToP   noToC   RFC1013 - Page 45
           request fails with status Frozen if the keyboard is
           frozen by an active grab of another client. The request
           fails with status NotViewable if grab-window is not
           viewable.  The request fails with status 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 replaced by the current server time.

UngrabKeyboard
           time: TIMESTAMP or CurrentTime

           Releases the keyboard if this client has it actively
           grabbed (from either GrabKeyboard or 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 and FocusOut events.

           An UngrabKeyboard is performed automatically if the event
           window for an active keyboard grab becomes not viewable.

GrabKey
           key: KEYCODE or AnyNonModifier
           modifiers: SETofKEYMASK or AnyModifier
           grab-window: WINDOW
           owner-events: BOOL
           pointer-mode, keyboard-mode: {Synchronous, Asynchronous}

           Errors: Window, Value, Access

           This request establishes a passive grab on the keyboard.
           In the future, if the specified key (which can itself be a
           modifier key) is pressed when the specified modifier keys
           are down (and no other modifier keys are down), and the
           KeyPress event would be generated in grab-window or one of
           its inferiors, and these constraints are not satisfied for
           any ancestor, then the keyboard is actively grabbed as
           described in GrabKeyboard, the last-keyboard-grab time is
           transmitted in set to the time at which the key was
           pressed (as in the KeyPress event), and the KeyPress
           event is reported.  The interpretation of the remaining
           arguments is as for GrabKeyboard.  The active grab is
           terminated automatically when the specified key has been
           released (independent of the state of the modifier keys).

           A modifiers of AnyModifier is equivalent to issuing the
           request for all possible modifier combinations.  A key of
           AnyNonModifier is equivalent to issuing the request for
ToP   noToC   RFC1013 - Page 46
           all possible non-modifier key codes.

           An Access error is generated if some other client has
           issued a GrabKey with the same key combination on the
           same window. When using AnyModifier or AnyNonModifier,
           the request fails  completely (no grabs are established)
           if there is a conflicting grab for any combination.

UngrabKey
           key: KEYCODE or AnyNonModifier
           modifiers: SETofKEYMASK or AnyModifier
           grab-window: WINDOW

           Errors: Window

           Releases the key combination on the specified window if it
           was grabbed by this client.  A modifiers of AnyModifier is
           equivalent to issuing the request for all possible
           modifier combinations.  A key of AnyNonModifier is
           equivalent to issuing the request for all possible
           non-modifier key codes.  Has no effect on an active grab.

AllowEvents
           mode: {AsyncPointer, SyncPointer, ReplayPointer,
                  AsyncKeyboard, SyncKeyboard, ReplayKeyboard}
           time: TIMESTAMP or CurrentTime

           Errors: Value

           Releases some queued events if the client has caused a
           device to freeze.  The request has no effect if the
           specified time is earlier than the last-grab time of the
           most recent active grab for the client, or if the
           specified time is later than the current server time.

           For 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 "thaws" for both.
           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, if the pointer is frozen and actively
           grabbed by the client, pointer event processing continues
           normally until the next ButtonPress or 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 has no effect if the pointer is not
           frozen by the client, or if the pointer is not grabbed by
ToP   noToC   RFC1013 - Page 47
           the client.

           For 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, or from a previous AllowEvents with mode
           SyncPointer, but not from a GrabPointer), then the pointer
           grab is released and that event is completely reprocessed,
           but this time ignoring any passive grabs at or above
           (towards the root) the grab-window of the grab just
           released.  The request has no effect if the pointer is
           not grabbed by the client, or if the pointer is not
           frozen as the result of an event.

           For AsyncKeyboard, if the keyboard is frozen by the
           client, keyboard event processing continues normally.  If
           the pointer is frozen twice by the client on behalf of
           two separate grabs, AsyncPointer "thaws" for both.
           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, if the keyboard is frozen and actively
           grabbed by the client, keyboard event processing
           continues normally until the next KeyPress or 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 has no
           effect if the keyboard is not frozen by the client, or
           if the keyboard is not grabbed by the client.

           For 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, or from a previous AllowEvents
           with mode SyncKeyboard, but not from a GrabKeyboard),
           then the keyboard grab is released and that event is
           completely reprocessed, but this time ignoring any passive
           grabs at or above (towards the root) the grab-window of
           the grab just released.  The request has no effect if the
           keyboard is not grabbed by the client, or if the keyboard
           is notfrozen as the result of an event.

           AsyncPointer, SyncPointer, and Replay Pointer have no
           effect on processing of keyboard events.  AsyncKeyboard,
           SyncKeyboard, and ReplayKeyboard have no effect on
           processing of pointer events.

           It is possible for both a pointer grab and a keyboard grab
           to be active simultaneously (by the same or different
ToP   noToC   RFC1013 - Page 48
           clients).  If a device is frozen on behalf of either grab,
           no event processing is performed for the device.  It is
           possible for a single device to be frozen due to both
           grabs.  In this case, the freeze must be released on
           behalf of both grabs before events can again be
           processed.

GrabServer
           Disables processing of requests and close-downs on all
           other connections (than the one this request arrived on).

UngrabServer
           Restarts processing of requests and close-downs on other
           connections.

QueryPointer
           window: WINDOW
       =>
           root: WINDOW
           child: WINDOW or None
           same-screen: BOOL
           root-x, root-y, win-x, win-y: INT16
           mask: SETofKEYBUTMASK

           Errors: Window

           The root window the pointer is currently on, and pointer
           coordinates relative to the root's origin, are returned.
           If same-screen is False, then the pointer is not on the
           same screen as the argument window, and child is None and
           win-x and win-y are zero.  If same-screen is 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.  The current state of the
           modifier keys and the buttons are also returned.

GetMotionEvents
           start, stop: TIMESTAMP or CurrentTime
           window: WINDOW
       =>
           events: LISTofTIMECOORD

           where
                   TIMECOORD: {x, y: CARD16
                               time: TIMESTAMP}

           Error: Window

           Returns all events in the motion history buffer that fall
           between the specified start and stop times (inclusive)
           and that have coordinates that lie within (including
ToP   noToC   RFC1013 - Page 49
           borders) the specified window at its present placement.
           The x and y coordinates are reported relative to the
           origin  of the window.

TranslateCoordinates
           src-window, dst-window: WINDOW
           src-x, src-y: INT16
       =>
           same-screen: BOOL
           child: WINDOW or None
           dst-x, dst-y: INT16

           Errors: Window

           The src-x and src-y coordinates are taken relative to
           src-window's origin, and returned as dst-x and dst-y
           coordinates relative to dst-window's origin.  If
           same-screen is 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, then that child is returned.

WarpPointer
           src-window: WINDOW or None
           dst-window: WINDOW
           src-x, src-y: INT16
           src-width, src-height: CARD16
           dst-x, dst-y: INT16

           Errors: Window

           Moves the pointer to [dst-x, dst-y] relative to
           dst-window's origin. If src-window is None, the move is
           independent of the current pointer position, but if a
           window is specified, the move only takes place if the
           pointer is currently contained in a visible portion of
           the specified rectangle of the src-window.

           The src-x and src-y coordinates are relative to
           src-window's origin.  If src-height is zero, it is
           replaced with the current height of src-window minus
           src-y.  If src-width is zero, it is replaced with the
           current width of src-window minus src-x.

           This request cannot be used to move the pointer outside
           the confine-to window of an active pointer grab; an
           attempt will only move the pointer as far as the closest
           edge of the confine-to window.
ToP   noToC   RFC1013 - Page 50
SetInputFocus
           focus: WINDOW or PointerRoot or None
           revert-to: {Parent, PointerRoot, None}
           time: TIMESTAMP or CurrentTime

           Errors: Window, Value

           Changes the input focus and the last-focus-change time.
           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
           replaced by the current server time.

           If None is specified as the focus, all keyboard events are
           discarded until a new focus window is set.  In this case,
           therevert-to argument is ignored.

           If a window is specified as the focus, it becomes the
           keyboard's focus window.  If a generated keyboard event
           would normally be reported to this window or one of its
           inferiors, the event is reported normally; otherwise, the
           event is reported with respect to the focus window.

           If 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.
           In this case, the revert-to argument is ignored.

           This request generates FocusIn and FocusOut events.

           If the focus window becomes not viewable, the new focus
           window depends on the revert-to argument.  If revert-to
           is Parent, the focus reverts to the parent (or the
           closest viewable ancestor) and the new revert-to value is
           take to be None.  If revert-to is PointerRoot or None,
           the focus reverts to that value.  When the focus reverts,
           FocusIn and FocusOut events are generated, but the
           last-focus-change time is not affected.

GetInputFocus
           =>
           focus: WINDOW or PointerRoot or None
           revert-to: {Parent, PointerRoot, None}

           Returns the current focus state.

QueryKeymap
       =>
           keys: LISTofCARD8
ToP   noToC   RFC1013 - Page 51
           Returns a bit vector for the keyboard; each one bit
           indicates that the corresponding key is currently pressed.
           The vector is represented as 32 bytes.  Byte N (from 0)
           contains the bits for keys 8N to 8N+7, with the least
           significant bit in the byte representing key 8N.

OpenFont
           fid: FONT
           name: STRING8

           Errors: IDChoice, Name, Alloc

           Loads the specified font, if necessary, and associates
           identifier fid with it.  The font can be used as a source
           for any drawable.  The font name should use the ASCII
           encoding, and upper/lower case does not matter.

CloseFont
           font: FONT

           Errors: Font

           Deletes the association between the resource id and the
           font.  The font itself will be freed when no other
           resource references it.

QueryFont
           font: FONT or GCONTEXT
       =>
           font-info: FONTINFO
           char-infos: LISTofCHARINFO

           where
                   FONTINFO: [draw-direction: {LeftToRight, RightToLeft}
                              min-char-or-byte2,max-char-or-byte2:CARD16
                              min-byte1, max-byte1: CARD8
                              all-chars-exist: BOOL
                              default-char: CARD16
                              min-bounds: CHARINFO
                              max-bounds: CHARINFO
                              font-ascent: INT16
                              font-descent: INT16
                              properties: LISTofFONTPROP]
                   FONTPROP: [name: ATOM
                              value: INT32 or CARD32]
                   CHARINFO: [left-side-bearing: INT16
                              right-side-bearing: INT16
                              character-width: INT16
                              ascent: INT16
                              descent: INT16
                              attributes: CARD16]
ToP   noToC   RFC1013 - Page 52
           Errors: Font

           Returns logical information about a font.

           The draw-direction is essentially just a hint, indicating
           whether most char-infos have a positive (LeftToRight) or a
           negative (RightToLeft)  character-width metric.  The core
           protocol defines no support for vertical text.

           If min-byte1 and max-byte1 are both zero, then
           min-char-or-byte2 specifies the linear character index
           corresponding to the first elementb of char-infos, and
           max-char-or-byte2 specifies the linear character index of
           the last element.  If either min-byte1 or max-byte1 are
           non-zero, then both min-char-or-byte2 and
           max-char-or-byte2 will be less than 256, and the two-byte
           character index values corresponding to char-infos element
           N (counting from 0) are
               byte1 = N/D + min-byte1
               byte2 = N\D + min-char-or-byte2
           where
               D = max-char-or-byte2 - min-char-or-byte2 + 1
               / = integer division
               \ = integer modulus

           If char-infos has length zero, then min-bounds and
           max-bounds will be identical, and the effective
           char-infos is one filled with this char-info, of length
               L = D * (max-byte1 - min-byte1 + 1)
           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, then all
           characters in char-infos have non-zero bounding boxes.

           The default-char specifies the character that will be
           used when an undefined or non-existent character is used.
           Note that default-char is a CARD16 (not CHAR2B); for a
           font using two-byte matrix format, the default-char has
           byte1 in the most significant byte, and byte2 in the
           least significant byte.  If the default-char itself
           specifies an undefined or non-existent character, then
           no printing is performed for an undefined or non-existent
           character.

           The min-bounds and max-bounds contain the minimum and
           maximum values of each individual CHARINFO component over
           all char-infos (ignoring non-existent characters).  The
           bounding box of the font, i.e., the smallest rectangle
           enclosing the shape obtained  by superimposing all
           characters at the same origin [x,y], has  its upper left
           coordinate at
ToP   noToC   RFC1013 - Page 53
               [x + min-bounds.left-side-bearing, y - max-bounds.
                    ascent] with a width of
               max-bounds.right-side-bearing - min-bounds.
                    left-side-bearing and a height of
               max-bounds.ascent + max-bounds.descent

           The font-ascent is the logical extent of the font above
           the baseline, for determining line spacing.  Specific
           characters may extend beyond this.  The font-descent is
           the logical extent of the font at or below the baseline,
           for determining line spacing. Specific characters may
           extend beyond this.  If the baseline is at Y-coordinate
           y, then the logical extent of the font is inclusive
           between the Y-coordinate values (y - font-ascent) and
           (y + font-descent - 1).

           A font is not guaranteed to have any properties.  Whether
           a property value is signed or unsigned must be derived
           from a prior knowledge of the property.  When possible,
           fonts should have at least the following properties (note
           that the trailing colon is not part of the name, and that
           upper/lower case matters).

           MIN_SPACE: CARD32
              The minimum interword spacing, in pixels.
           NORM_SPACE: CARD32
               The normal interword spacing, in pixels.
           MAX_SPACE: CARD32
               The maximum interword spacing, in pixels
           SUBSCRIPT_X: INT32
           SUBSCRIPT_Y: INT32
               Offsets from the character origin where subscripts
               should begin, in pixels.  If the origin is at [x,y],
               then subscripts should begin at [x + SubscriptX,
                   y + SubscriptY].
           UNDERLINE_POSITION: INT32
               Y offset from the baseline to the top of an underline,
               in pixels. If the baseline is Y-coordinate y, then
               the top of the underline is at (y +
                    UnderlinePosition).
           UNDERLINE_THICKNESS: CARD32
               Thickness of the underline, in pixels.
           STRIKEOUT_ASCENT: INT32
           STRIKEOUT_DESCENT: INT32
               Vertical extents for boxing or voiding characters, in
               pixels.  If the baseline is at Y-coordinate y, then
               the top of the strikeout box is at (y -
               StrikeoutAscent), and the height of the box is
               (StrikeoutAscent +  StrikeoutDescent).
           ITALIC_ANGLE: INT32
               The angle of characters in the font, in degrees
ToP   noToC   RFC1013 - Page 54
               scaled by 64, relative to the three-oclock position
               from the character origin, with positive indicating
               counterclockwise motion (as in Arc requests).
           X_HEIGHT: INT32
               "1 ex" as in TeX, but expressed in units of pixels.
               Often the height of lowercase x.
           QUAD_WIDTH: INT32
               "1 em" as in TeX, but expressed in units of pixels.
               Often the width of the digits 0-9.
           WEIGHT: CARD32
               The weight or boldness of the font, expressed as a
               value between 0 and 1000.
           POINT_SIZE: CARD32
               The point size, expressed in 1/10ths, of this font at
               the ideal resolution.  There are 72.27 points to the
               inch.
           RESOLUTION: CARD32
               The number of pixels per point, expressed in 1/100ths,
               at which this font was created.

           For a character origin at [x,y], the bounding box of a
           character,i.e., the smallest rectangle enclosing the
           character's shape,  described in terms of CHARINFO
           components, is a rectangle with its upper left corner at
                   [x + left-side-bearing, y - ascent]
           with a width of
                   right-side-bearing - left-side-bearing
           and a height of
                   ascent + descent
           and the origin for the next character is defined to be
                   [x + character-width, y]
           Note that the baseline is logically viewed as being just
           below non-descending characters (when descent is zero,
           only pixels with Y-coordinates less than y are drawn),
           and that the origin is logically viewed as being
           coincident with the left edge of a non-kerned character
           (when left-side-bearing is zero, no pixels with
           X-coordinate less than x are drawn).

           Note that CHARINFO metric values can be negative.

           A non-existent character is represented with all CHARINFO
           components zero.

           The interpretation of the per-character attributes field
           is undefined by the core protocol.

QueryTextExtents
           font: FONT or GCONTEXT
           items: STRING16
       =>
ToP   noToC   RFC1013 - Page 55
           draw-direction: {LeftToRight, RightToLeft}
           font-ascent: INT16
           font-descent: INT16
           overall-ascent: INT16
           overall-descent: INT16
           overall-width: INT32
           overall-left: INT32
           overall-right: INT32

           Errors: Font

           Returns the logical extents of the specified string of
           characters in the specified font.  Draw-direction,
           font-ascent, and font-descent are as described in
           QueryFont.  Overall-ascent is the maximum of the ascent
           metrics of all characters in the string, and
           overall-descent is the maximum of the descent metrics.
           Overall-width is the sum of the character-width metrics
           of all characters in the string.  For each character in
           the string, let W be the sum of the character-width
           metrics of all characters preceding it in the string,
           let L be the left-side-bearing metric of the character
           plus W, and let R be the right-side-bearing metric of
           the character plus W.  Overall-left is the minimum L of
           all characters in the string, and overall-right is the
           maximum R.

           For fonts defined with linear indexing rather than
           two-byte matrix indexing, the server will interpret each
           CHAR2B as a 16-bit number that has been transmitted most
           significant byte first (i.e., byte1 of the CHAR2B is
           taken as the most significant byte).

           If the font has no defined default-char, then undefined
           characters in   the string are taken to have all zero
           metrics.
ListFonts
           pattern: STRING8
           max-names: CARD16
       =>
           names: LISTofSTRING8

           Returns a list of length at most max-names, of names of
           fonts matching the pattern.  The pattern should use the
           ASCII encoding, and upper/lower case does not matter.
           In the pattern, the '?' character (octal value 77) will
           match any single character, and the character '*' (octal
           value 52) will match any number of characters.  The
           returned names are in lower case.
ToP   noToC   RFC1013 - Page 56
ListFontsWithInfo
           pattern: STRING8
           max-names: CARD16
       =>
           fonts: LISTofFONTDATA

           where
                   FONTDATA: [name: STRING8
                              info: FONTINFO]
                   FONTINFO: <same type definition as in QueryFont>

           Like ListFonts, but also returns information about each
           font.  The information returned for each font is
           identical to what QueryFont would return (except that the
           per-character metrics are not returned).

SetFontPath
           path: LISTofSTRING8

           Errors: Value

           Defines the search path for font lookup.  There is only one
           search path per server, not one per client.  The
           interpretation of the strings is operating system dependent,
           but they are intended to specify directories to be
           searched in the order listed.

           Setting the path to the empty list restores the default
           path defined for the server.

           As a side-effect of executing this request, the server
           is guaranteed to flush all cached information about fonts
           for which there currently are no explicit resource ids
           allocated.

           The meaning of an error from this request is system
           specific.

GetFontPath
       =>
           path: LISTofSTRING8

           Returns the current search path for fonts.

CreatePixmap
           pid: PIXMAP
           drawable: DRAWABLE
           depth: CARD8
           width, height: CARD16

           Errors: IDChoice, Drawable, Value, Alloc
ToP   noToC   RFC1013 - Page 57
           Creates a pixmap, and assigns the identifier pid to it.
           Width and height must be non-zero.  Depth must be one of
           the depths supported by root of the specified drawable.
           The initial contents of the pixmap are undefined.

           It is legal to pass an InputOnly window as a drawable to
           this request.

FreePixmap
           pixmap: PIXMAP

           Errors: Pixmap

           Deletes the association between the resource id and the
           pixmap.  The pixmap storage will be freed when no other
           resource references it.

CreateGC
           cid: GCONTEXT
           drawable: DRAWABLE
           value-mask: BITMASK
           value-list: LISTofVALUE

           Errors: IDChoice, Drawable, Pixmap, Font, Match, Value, Alloc

           Creates a graphics context, 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.

           The value-mask and value-list specify which components are to
           be explicitly initialized.  The context components are:

             alu-function: {Clear, And, AndReverse, Copy, AndInverted,
                            Noop, Xor, Or, Nor, Equiv, Invert,
                              OrReverse, CopyInverted, OrInverted,
                              Nand, Set}
             plane-mask: CARD32
             foreground: CARD32
             background: CARD32
             line-width: CARD16
             line-style: {Solid, OnOffDash, DoubleDash}
             cap-style: {NotLast, Butt, Round, Projecting}
             join-style: {Miter, Round, Bevel}
             fill-style: {Solid, Tiled, OpaqueStippled, Stippled}
             fill-rule: {EvenOdd, Winding}
             arc-mode: {Chord, PieSlice}
             tile: PIXMAP
             stipple: PIXMAP
             tile-stipple-x-origin: INT16
             tile-stipple-y-origin: INT16
             font: FONT
ToP   noToC   RFC1013 - Page 58
             subwindow-mode: {ClipByChildren, IncludeInferiors}
             graphics-exposures: BOOL
             clip-x-origin: INT16
             clip-y-origin: INT16
             clip-mask: PIXMAP or None
             dash-offset: CARD16
             dash-list: CARD8

           In graphics operations, given a source and destination pixel,
           the result is computed bitwise on corresponding bits of the
           pixels.  That is, a boolean operation is performed in each
           bit plane. The plane-mask restricts the operation to a subset
           of planes.  That is, the result is

           ((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))

           Range checking is not performed on the values for foreground,
           background, or plane-mask; they are simply truncated to the
           appropriate number of bits.

           The meanings of the alu-functions are:

               Clear               0
               And                 src AND dst
               AndReverse          src AND (NOT dst)
               Copy                src
               AndInverted         (NOT src) AND dst
               NoOp                dst
               Xor                 src XOR dst
               Or                  src OR dst
               Nor                 (NOT src) AND (NOT dst)
               Equiv               (NOT src) XOR dst
               Invert              NOT dst
               OrReverse           src OR (NOT dst)
               CopyInverted        NOT src
               OrInverted          (NOT src) OR dst
               NAnd                (NOT src) OR (NOT dst)
               Set                 1

           Line-width is measured in pixels and can be greater than or
           equal to one (a "wide" line) or the special value zero (a
           "thin" line).

           Wide lines are drawn centered on the path described by the
           graphics request.  Unless otherwise specified by the join or
           cap style, the bounding box of a wide line with endpoints
           [x1, y1], [x2, y2], and width w is a rectangle with vertices
           at the following real coordinates:

           [x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
           [x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
ToP   noToC   RFC1013 - Page 59
           where sn is the sine of the angle of the line and cs is the
           cosine of the angle of the line.  A pixel is part of the line
           (and hence drawn) if the center of the pixel is fully inside
           the bounding box (which is viewed as having infinitely thin
           edges).  If the center of the pixel is exactly on the
           bounding box, it is part of the line if and only if the
           interior is immediately to its right (x increasing
           direction).  Pixels with centers on a horizontal edge are a
           special case and are part of the line if and only if the
           interior is immediately below (y increasing direction).
           Note that this description is a mathematical model
           describing the pixels that are drawn for a wide line and
           does not imply that trigonometry is required to implement
           such a model.  Real or fixed point arithmetic is
           recommended for computing the corners of the line endpoints
           for lines greater than one pixel in width.

           Thin lines (zero line-width) are "one pixel wide" lines drawn
           using an unspecified, device dependent algorithm (for
           example, Bresenham). There are only two constraints on this
           algorithm. First, if a line is drawn unclipped from [x1,y1]
           to [x2,y2] and another line is drawn unclipped from [x1+dx,
           y1+dy] to [x2+dx,y2+dy], then a point [x,y] is touched by
           drawing the first line if and only if the point [x+dx,y+dy]
           is touched by drawing the second line.  Second, the effective
           set of points comprising a line cannot be affected by
           clipping; that is, a point is touched in a clipped line if
           and only if the point lies inside the clipping region and
           the point would be touched by the line when drawn unclipped.

           Note that a wide line drawn from [x1,y1] to [x2,y2] always
           draws the same pixels as a wide line drawn from [x2,y2] to
           [x1,y1], not counting cap and join styles, but this property
           is not guaranteed for thin lines.  Also note that "jags" in
           adjacent wide lines will always line up properly, but this
           property is not guaranteed for thin lines.  A line-width of
           zero differs from a line-width of one in which pixels are
           drawn.  In general, drawing a thin line will be faster than
           drawing a wide line of width one, but thin lines may not mix
           well aesthetically desirable to obtain precise and uniform
           results across all displays, a client should always use a
           line-width of one, rather than a line-width of zero.

           The line-style defines which segments of a line are drawn:
               Solid:  the full path of the line is drawn
               DoubleDash: the full path of the line is drawn, but the
                           segments defined by the even dashes are
                           filled differently than the segments defined
                           by the odd dashes (see fill-style)
               OnOffDash: only the segments defined by the even dashes
                          are drawn, and cap-style applies to each
ToP   noToC   RFC1013 - Page 60
                          individual segment (except NotLast is treated
                          as Butt for internal caps)

           The cap-style defines how the endpoints of a path are drawn:
               NotLast: equivalent to Butt, except that for a
                        line-width of zero or one the final endpoint is
                        not drawn
               Butt: square at the endpoint, with no projection beyond
               Round: a circular arc with diameter equal to the
                      line-width, centered on the endpoint; equivalent
                      to Butt for line-width zero or one
               Projecting: square at the end, but the path continues
                           beyond the endpoint for a distance equal to
                           half the line-width; equivalent to Butt for
                           line-width zero or one

           The join-style defines how corners are drawn for wide lines:
               Miter: the outer edges of the two lines extend to meet at
                      an angle
               Round: a circular arc with diameter equal to the
                      line-width, centered on the joinpoint
               Bevel: Butt endpoint styles, and then the triangular
                      "notch" filled

           The tile/stipple and clip origins are interpreted relative to
           the origin of whatever destination drawable is specified in a
           graphics request.

           The tile pixmap must have the same root and depth as the
           gcontext (else a Match error).  The stipple pixmap must have
           depth one, and must have the same root as the gcontext (else
           a Match error).  For stipple operations, 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, although some sizes may be
           faster to use than others.

           The fill-style defines the contents of the source for line,
           text, and fill requests.  For all text and fill requests
           (PolyText8, PolyText16, PolyFillRectangle, FillPoly,
           PolyFillArc), for line  requests (PolyLine, PolySegment,
           PolyRectangle, PolyArc) with line-style Solid, and for the
           even dashes for line requests with line-style OnOffDash or
           DoubleDash:
               Solid: foreground
               Tiled: tile
               OpaqueStippled: a tile with the same width and height as
                               stipple, but with background everywhere
                               stipple has a zero and with foreground
                               everywhere stipple has a one
               Stippled: foreground masked by stipple
ToP   noToC   RFC1013 - Page 61
           For the odd dashes for line requests with line-style
           DoubleDash:
               Solid: background
               Tiled: same as for even dashes
               OpaqueStippled: same as for even dashes
               Stippled: background masked by stipple

           The dash-list value allowed here is actually a simplified
           form of the more general patterns that can be set with
           SetDashes.Specifying a value of N here is equivalent to
           specifying the two element list [N, N] in SetDashes.  The
           value must be non-zero.  The meaning of dash-offset and
           dash-list are explained in the SetDashes request.

           The clip-mask restricts writes to the destination drawable;
           only pixels where the clip-mask has a one bit are drawn.  It
           affects all graphics requests.  The clip-mask does not clip
           sources.  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 one and have the same root as the gcontext
           (else a Match error).  The clip-mask can also be set with the
           SetClipRectangles request.

           For ClipByChildren, both source and destination windows are
           additionally clipped by all viewable InputOutput children.
           For IncludeInferiors, neither source nor destination window
           is clipped by inferiors; this will result in drawing through
           subwindow boundaries. The use of IncludeInferiors on a window
           of one depth with mapped inferiors of differing depth is not
           illegal, but the semantics isundefined by the core protocol.

           The fill-rule defines what pixels are inside (i.e., are
           drawn) for paths given in FillPoly requests.  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, a
           point is inside if an infinite ray with the point as origin
           crosses an unequal number of clockwise and counterclockwise
           directed path segments.  For both rules, a "point" is
           infinitely small, and the path is an infinitely thin line.
           A pixel is inside if the center point of the pixel is inside
           and the center point is not on the boundary.  If the center
           point is on the boundary, the pixel is inside if and only if
           the polygon interior is immediately to its right (x
           increasing direction).  Pixels with centers along a
           horizontal edge are a special case and are inside if and
           only if the polygon interior is immediately below (y
           increasing direction).

           The arc-mode controls filling in the PolyFillArc request.
ToP   noToC   RFC1013 - Page 62
           The graphics-exposures flag controls GraphicsExposure event
           generation for CopyArea and CopyPlane requests (and any
           similar requests defined by extensions).

           The default component values are:
               function: Copy
               plane-mask: all ones
               foreground: 0
               background: 1
               line-width: 0
               line-style: Solid
               cap-style: Butt
               join-style: Miter
               fill-style: Solid
               full-rule: EvenOdd
               arc-mode: PieSlice
               tile: pixmap of unspecified size filled with forground
                     pixell (i.e., client specified pixel if any,
                     else 0)
               stipple: pixmap of unspecified size filled with ones
               tile-stipple-x-origin: 0
               tile-stipple-y-origin: 0
               font: <implementation dependent>
               subwindow-mode: ClipByChildren
               graphics-exposures: True
               clip-x-origin: 0
               clip-y-origin: 0
               clip-mask: None
               dash-offset: 0
               dash-list: 4 (i.e., the list [4, 4])

           Storing a pixmap in a gcontext might or might not result in a
           copy being made.  If the pixmap is later used as the
           destination for a graphics request, the change might or might
           not be reflected in the gcontext.  If the pixmap is used
           simultaneously  in a graphics request as both a destination
           and as a tile or stipple. the results are not defined.

           It is quite likely that some amount of gcontext information
           will be cached in display hardware, and that such hardware
           can only cache a small number of gcontexts.  Given the number
           and complexity of components, clients should view switching
           between gcontexts with nearly identical state as
           significantly more expensive than making minor changes to a
           single gcontext.

ChangeGC
           gc: GCONTEXT
           value-mask: BITMASK
           value-list: LISTofVALUE
ToP   noToC   RFC1013 - Page 63
           Errors: GContext, Pixmap, Font, Match, Value, Alloc

           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.

           Changing the clip-mask also overrides any previous
           SetClipRectangles request on the context.  Changing the
           dash-offset or dash-list overrides any previous SetDashes
           request on the context.

           The order in which components are verified and altered is
           server dependent.  If an error is generated, a subset of the
           components may have been altered.

CopyGC
           src-gc, dst-gc: GCONTEXT
           value-mask: BITMASK

           Errors: GContext, Value, Match, Alloc

           Copies components from src-gc to dst-gc.  The value-mask
           specifies which components to copy, as for CreateGC.  The
           two gcontexts must have the same root and the same depth
           (else a Match error).

SetDashes
           gc: GCONTEXT
           dash-offset: CARD16
           dash-list: LISTofCARD8

           Errors: GContext, Value, Alloc

           Sets the dash-offset and dash-list in gc for dashed line
           styles.  The initial and alternating elements of the
           dash-list are the "even" dashes, the others are the
           "odd" dashes.  All of the elements must be non-zero.
           The dash-offset defines the phase of the pattern,
           specifying how many pixels into the dash-list the pattern
           should actually begin in any single graphics request.
           Dashing is continuous through path segments combined with
           a join-style, but is reset to the dash-offset each time a
           cap-style is applied.

SetClipRectangles
           gc: GCONTEXT
           clip-x-origin, clip-y-origin: INT16
           rectangles: LISTofRECTANGLE
           ordering: {UnSorted, YSorted, YXSorted, YXBanded}

           Errors: GContext, Value, Alloc, Match
ToP   noToC   RFC1013 - Page 64
           Changes clip-mask in gc to the specified list of rectangles
           and sets the clip origin.  Output will be clipped to remain
           contained within the rectangles.  The clip origin is
           interpreted relative to the origin of whatever destination
           drawable is specified in a graphics request.  The rectangle
           coordinates are interpreted relative to the clip origin.
           The rectangles should be non-intersecting, or graphics
           results will be undefined.

           If known by the client, ordering relations on the rectangles
           can be specified with the ordering argument; this may provide
           faster operation by the server.  If an incorrect ordering is
           specified, the server may generate a Match error, but is not
           required to do so; if no error is generated, the graphics
           results are undefined. UnSorted means the rectangles are in
           arbitrary order.  YSorted means that the rectangles are
           non-decreasing in their Y origin. YXSorted additionally
           constrains YSorted order in that all rectangles with an equal
           Y origin are non-decreasing in their X origin.  YXBanded
           additionally constrains YXSorted by requiring that for every
           possible Y scanline, all rectangles that include that
           scanline have identical Y origins and Y extents.

FreeGC
           gc: GCONTEXT

           Errors: GContext

           Deletes the association between the resource id and the
           gcontext, and destroys the gcontext.

ClearToBackground
           window: WINDOW
           x, y: INT16
           width, height: CARD16
           exposures: BOOL

           Errors: Window, Value, Match

           The x and y coordinates are relative to the window's origin,
           and specify the upper left corner of the rectangle.  If width
           is zero, it is replaced with the current width of the window
           minus x.  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 alu-function of Copy.  If the window has
           background None, the contents of the window are not changed.
           In eithercase, if  exposures is True, then one or more
           exposure events are generated for regions of the rectangle
           that are eithervisible or are being retained in a backing
           store.


(next page on part 3)

Next Section