| [Top] | +[Contents] | +[Index] | +[ ? ] | +
This manual documents the X Interface for SCM Language (version +5e5, February 2008). +
+Copyright © 1999 Free Software Foundation, Inc. +
++ +Permission is granted to make and distribute verbatim copies of +this manual provided the copyright notice and this permission notice +are preserved on all copies. +
+Permission is granted to copy and distribute modified versions of this +manual under the conditions for verbatim copying, provided that the entire +resulting derived work is distributed under the terms of a permission +notice identical to this one. +
+Permission is granted to copy and distribute translations of this manual +into another language, under the above conditions for modified versions, +except that this permission notice may be stated in a translation approved +by the author. +
| 1. XlibScm | + | |
| 2. Display and Screens | + | |
| 3. Drawables | + | |
| 4. Graphics Context | + | |
| 5. Cursor | + | |
| 6. Colormap | + | |
| 7. Rendering | + | |
| 8. Images | + | |
| 9. Event | + | |
| Indexes | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
XlibScm is a SCM interface to X.
+
+The
+<A HREF="http://www.x.org/">
+X Window System
+</A>
+is a network-transparent window system that was
+designed at MIT.
+<A HREF="scm_toc.html">
+SCM
+</A>
+is a portable Scheme implementation written in C.
+The interface can be compiled into SCM or, on those platforms supporting
+dynamic linking, compiled separately and loaded with (require
+'Xlib).
+
+
Much of this X documentation is dervied from: +
+Xlib - C Language X Interface +
X Consortium Standard +
X Version 11, Release 6.3 +
+The X Window System is a trademark of X Consortium, Inc. +
+TekHVC is a trademark of Tektronix, Inc. +
+ + +Copyright (C) 1985, 1986, 1987, 1988, 1989, 1990, 1991, 1994, 1996 X +Consortium +
+Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the +"Software"), to deal in the Software without restriction, including +without limitation the rights to use, copy, modify, merge, publish, +distribute, sublicense, and/or sell copies of the Software, and to +permit persons to whom the Software is furnished to do so, subject to +the following conditions: +
+The above copyright notice and this permission notice shall be included +in all copies or substantial portions of the Software. +
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS +OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. +IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR +OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +OTHER DEALINGS IN THE SOFTWARE. +
+Except as contained in this notice, the name of the X Consortium shall +not be used in advertising or otherwise to promote the sale, use or +other dealings in this Software without prior written authorization from +the X Consortium. +
+ + + +Copyright (C) 1985, 1986, 1987, 1988, 1989, 1990, 1991 by +Digital Equipment Corporation +
+Portions Copyright (C) 1990, 1991 by Tektronix, Inc. +
+Permission to use, copy, modify and distribute this documentation for +any purpose and without fee is hereby granted, provided that the above +copyright notice appears in all copies and that both that copyright +notice and this permission notice appear in all copies, and that the +names of Digital and Tektronix not be used in in advertising or +publicity pertaining to this documentation without specific, written +prior permission. Digital and Tektronix makes no representations about +the suitability of this documentation for any purpose. It is provided +“as is” without express or implied warranty. +
+ +| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
display-name Specifies the hardware display name, which determines +the display and communications domain to be used. On a POSIX-conformant +system, if the display-name is #f, it defaults to the value of the +DISPLAY environment variable. +
+The encoding and interpretation of display-name is +implementation-dependent. On POSIX-conformant systems, the +display-name or DISPLAY environment variable can be a string +in the format: +
+hostname specifies the name of the host machine on which the +display is physically attached. Follow the hostname with either a +single colon (:) or a double colon (::). +
+number specifies the number of the display server on that host +machine. You may optionally follow this display number with a period +(.). A single CPU can have more than one display. Multiple displays +are usually numbered starting with zero. +
+screen-number specifies the screen to be used on that server. +Multiple screens can be controlled by a single X server. The +screen-number sets an internal variable that can be accessed by +using the x:default-screen procedure. +
display specifies the connection to the X server. +
+The x:close function closes the connection to the X server for
+the display specified and destroys all windows, resource IDs
+(Window, Font, Pixmap, Colormap, Cursor, and GContext), or other
+resources that the client has created on this display, unless the
+close-down mode of the resource has been changed (see
+x:set-close-down-mode). Therefore, these windows, resource IDs,
+and other resources should not be used again or an error will be
+generated. Before exiting, you should call x:close-display or
+x:flush explicitly so that any pending errors are reported.
+
Returns cons of the major version number (11) of the X protocol +associated with the connected display and the minor protocol +revision number of the X server. +
Returns a string that provides some identification of the owner of the X +server implementation. The contents of the string are +implementation-dependent. +
Returns a number related to a vendor’s release of the X server. +
A display consists of one or more Screens. Each screen has a +root-window, default-graphics-context, and colormap. +
+ + +Returns the default screen number specified by the x:open-display
+function. Use this screen number in applications which will use only a
+single screen.
+
screen-number, if givien, specifies the appropriate screen number +on the host server. Otherwise the default-screen for display is +used. +
+Returns the root window for the specified screen-number. Use
+x:root-window for functions that need a drawable of a particular
+screen or for creating top-level windows.
+
Returns the root window for the specified window’s screen. +
Returns the default colormap of the specified screen. +
Returns the default Color-Conversion-Context (ccc) of the specified +screen. +
Returns the default graphics-context of the specified screen. +
Returns an array of depths supported by the specified screen. +
The Visual type describes possible colormap depths and +arrangements. +
+Returns the default Visual type for the specified screen. +
+ + +The integer depth specifies the number of bits per pixel. +The class argument specifies one of the possible +visual classes for a screen: +
X:make-visual returns a visual type for the screen specified by
+display or window if successful; #f if not.
+
Returns the (integer) visual class of its argument. +
Returns a list of the: +
Returns the number of entries in the default colormap. +
Returns the depth of the root window of the specified screen. +
Returns the depth of argument. +
+ +The depth of a window or pixmap is the number of bits per pixel it has. +The depth of a graphics context is the depth of the drawables it can be +used in conjunction with graphics output. +
Returns a list of integer height and width of the screen in pixels. +
Returns a list of integer height and width of the screen in millimeters. +
Returns the white pixel value of the specified screen. +
Returns the black pixel value of the specified screen. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
A Drawable is either a window or pixmap. +
+| 3.1 Windows and Pixmaps | + | |
| 3.2 Window Attributes | + | |
| 3.3 Window Properties and Visibility | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Creates and returns an unmapped Input-Output subwindow for a specified +parent window and causes the X server to generate a CreateNotify +event. The created window is placed on top in the stacking order with +respect to siblings. Any part of the window that extends outside its +parent window is clipped. The border-width for an +x:Input-Only window must be zero. +
+The coordinate system has the X axis horizontal and the Y axis vertical +with the origin [0, 0] at the upper-left corner. Coordinates are +integral, in terms of pixels, and coincide with pixel centers. Each +window and pixmap has its own coordinate system. For a window, the +origin is inside the border at the inside, upper-left corner. +
+Class can be x:Input-Output, x:Input-Only, or x:Copy-From-Parent. +For class x:Input-Output, the visual type and depth must be +a combination supported for the screen. The depth need not be the +same as the parent, but the parent must not be a window of class +x:Input-Only. For an x:Input-Only window, the depth must be zero, +and the visual must be one supported by the screen. +
+The returned window will have the attributes specified by +field-names and value. +
+The returned window inherits its depth, class, and visual from its +parent. All other window attributes, except background and +border, have their default values. +
size is a list, vector, or pair of nonzero integers specifying the width +and height desired in the new pixmap. +
+x:create-pixmap returns a new pixmap of the width, height, and +depth specified. It is valid to pass an x:Input-Only window to the +drawable argument. The depth argument must be one of the depths +supported by the screen of the specified drawable. +
Destroys the specified window as well as all of its subwindows and +causes the X server to generate a DestroyNotify event for each window. +The window should not be used again. If the window specified by the +window argument is mapped, it is unmapped automatically. The +ordering of the DestroyNotify events is such that for any given window +being destroyed, DestroyNotify is generated on any inferiors of the +window before being generated on the window itself. The ordering among +siblings and across subhierarchies is not otherwise constrained. If the +window you specified is a root window, an error is signaled. +Destroying a mapped window will generate x:Expose events on other +windows that were obscured by the window being destroyed. +
Deletes the association between the pixmap and its storage. The X +server frees the pixmap storage when there are no references to it. +
Returns a list of: +
+list of x and y coordinates that define the location of the
+drawable. For a window, these coordinates specify the upper-left
+outer corner relative to its parent’s origin. For pixmaps, these
+coordinates are always zero.
+
list of the drawable’s dimensions (width and height). For
+a window, these dimensions specify the inside size, not including the
+border.
+
The border width in pixels. If the drawable is a pixmap, this is +zero. +
The depth of the drawable (bits per pixel for the object). +
Changes the Configuration components specified by +field-names for the specified window. +
These are the attributes settable by x:window-geometry-set!.
+That these attributes are encoded by small integers – just like those
+of the next section. Be warned therefore that confusion of attribute
+names will likely not signal errors, just cause mysterious behavior.
+
The x:CWX and x:CYY members are used to set the window’s x and y +coordinates, which are relative to the parent’s origin and indicate the +position of the upper-left outer corner of the window. The x:CW-Width +and x:CW-Height members are used to set the inside size of the window, +not including the border, and must be nonzero. Attempts to configure a +root window have no effect. +
+If a window’s size actually changes, the window’s subwindows move +according to their window gravity. Depending on the window’s bit +gravity, the contents of the window also may be moved +
The integer x:CW-Border-Width is used to set the width of the border in +pixels. Note that setting 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 an error to set the border-width +attribute of an InputOnly window nonzero. +
The sibling member is used to set the sibling window for stacking +operations. +
The x:CW-Stack-Mode member is used to set how the window is to be +restacked and can be set to x:Above, x:Below, x:Top-If, x:Bottom-If, or +x:Opposite. +
If a sibling and a stack-mode are specified, the window is restacked as +follows: +
+x:AboveThe window is placed just above the sibling. +
x:BelowThe window is placed just below the sibling. +
x:Top-IfIf the sibling occludes the window, the window is placed at the top of +the stack. +
x:Bottom-IfIf the window occludes the sibling, the window is placed at the bottom +of the stack. +
x:OppositeIf the sibling occludes the window, the window is placed at the top of +the stack. If the window occludes the sibling, the 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: +
+x:AboveThe window is placed at the top of the stack. +
x:BelowThe window is placed at the bottom of the stack. +
x:Top-IfIf any sibling occludes the window, the window is placed at the top of +the stack. +
x:Bottom-IfIf the window occludes any sibling, the window is placed at the bottom +of the stack. +
x:OppositeIf any sibling occludes the window, the window is placed at the top of +the stack. If the window occludes any sibling, the window is placed at +the bottom of the stack. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Changes the components specified by field-names for the specified
+window. The restrictions are the same as for
+x:create-window. The order in which components are verified and
+altered is server dependent. If an error occurs, a subset of the
+components may have been altered.
+
The x:create-window and x:window-set! procedures take five
+and one argument (respectively) followed by pairs of arguments, where
+the first is one of the property-name symbols (or its top-level value)
+listed below; and the second is the value to associate with that
+property.
+
Sets the background pixmap of the window to the specified pixmap. +The background pixmap can immediately be freed if no further explicit +references to it are to be made. If x:Parent-Relative is specified, the +background pixmap of the window’s parent is used, or on the root window, +the default background is restored. It is an error to perform this +operation on an x:Input-Only window. If the background is set to #f or +None, the window has no defined background. +
Sets the background of the window to the specified pixel value. +Changing the background does not cause the window contents to be +changed. It is an error to perform this operation on an x:Input-Only +window. +
Sets the border pixmap of the window to the pixmap you specify. +The border pixmap can be freed if no further explicit references to it +are to be made. If you specify x:Copy-From-Parent, a copy of the parent +window’s border pixmap is used. It is an error to perform this +operation on an x:Input-Only window. +
Sets the border of the window to the pixel value. It is an +error to perform this operation on an x:Input-Only window. +
The bit gravity of a window defines which region of the window should be +retained when an x:Input-Output window is resized. The default value +for the bit-gravity attribute is x:Forget-Gravity. The window gravity +of a window allows you to define how the x:Input-Output or x:Input-Only +window should be repositioned if its parent is resized. The default +value for the win-gravity attribute is x:North-West-Gravity. +
+If the inside width or height of a window is not changed and if the +window is moved or its border is changed, then the contents of the +window are not lost but move with the window. Changing the inside width +or height of the window causes its contents to be moved or lost +(depending on the bit-gravity of the window) and causes children to be +reconfigured (depending on their win-gravity). For a change of width +and height, the (x, y) pairs are defined: +
+| Gravity Direction | Coordinates |
| x:North-West-Gravity | (0, 0) |
| x:North-Gravity | (Width/2, 0) |
| x:North-East-Gravity | (Width, 0) |
| x:West-Gravity | (0, Height/2) |
| x:Center-Gravity | (Width/2, Height/2) |
| x:East-Gravity | (Width, Height/2) |
| x:South-West-Gravity | (0, Height) |
| x:South-Gravity | (Width/2, Height) |
| x:South-East-Gravity | (Width, Height) |
When a window with one of these bit-gravity values 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 +x:Gravity-Notify event is generated (see section 10.10.5). +
+A bit-gravity of x:Static-Gravity 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 (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 x:Static-Gravity still only +takes effect when the width or height of the window is changed, not when +the window is moved. +
+A bit-gravity of x:Forget-Gravity indicates that the window’s contents +are always discarded after a size change, even if a backing store or +save under has been requested. The window is tiled with its background +and zero or more x:Expose events are generated. If no background is +defined, the existing screen contents are not altered. Some X servers +may also ignore the specified bit-gravity and always generate x:Expose +events. +
+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 x:Forget-Gravity instead. +
+A win-gravity of x:Unmap-Gravity is like x:North-West-Gravity (the +window is not moved), except the child is also unmapped when the parent +is resized, and an x:Unmap-Notify event is generated. +
Some implementations of the X server may choose to maintain the contents +of x:Input-Output windows. If the X server maintains the contents of a +window, the off-screen saved pixels are known as backing store. The +backing store advises the X server on what to do with the contents of a +window. The backing-store attribute can be set to x:Not-Useful +(default), x:When-Mapped, or x:Always. A backing-store attribute of +x:Not-Useful advises the X server that maintaining contents is +unnecessary, although some X implementations may still choose to +maintain contents and, therefore, not generate x:Expose events. A +backing-store attribute of x:When-Mapped advises the X server that +maintaining contents of obscured regions when the window is mapped would +be beneficial. In this case, the server may generate an x:Expose event +when the window is created. A backing-store attribute of x:Always +advises the X server that maintaining contents even when the window is +unmapped would be beneficial. Even if the window is larger than its +parent, this is a request to the X server to maintain complete contents, +not just the region within the parent window boundaries. While the X +server maintains the window’s contents, x:Expose events normally are not +generated, but the X server may stop maintaining contents at any time. +
+When the contents of obscured regions of a window are being maintained, +regions obscured by noninferior windows are included in the destination +of graphics requests (and source, when the window is the source). +However, regions obscured by inferior windows are not included. +
You can set backing planes to indicate (with bits set to 1) which bit +planes of an x:Input-Output window hold dynamic data that must be +preserved in backing store and during save unders. The default value +for the backing-planes attribute is all bits set to 1. You can set +backing pixel to specify what bits to use in planes not covered by +backing planes. The default value for the backing-pixel attribute is +all bits set to 0. The X server is free to save only the specified bit +planes in the backing store or the save under and is free to regenerate +the remaining planes with the specified pixel value. Any extraneous +bits in these values (that is, those bits beyond the specified depth of +the window) may be simply ignored. If you request backing store or save +unders, you should use these members to minimize the amount of +off-screen memory required to store your window. +
To control window placement or to add decoration, a window manager often +needs to intercept (redirect) any map or configure request. Pop-up +windows, however, often need to be mapped without a window manager +getting in the way. To control whether an x:Input-Output or +x:Input-Only window is to ignore these structure control facilities, use +the override-redirect flag. +
+The override-redirect flag specifies whether map and configure requests +on this window should override a x:Substructure-Redirect-Mask on the +parent. You can set the override-redirect flag to #t or #f (default). +Window managers use this information to avoid tampering with pop-up +windows. +
Some server implementations may preserve contents of x:Input-Output windows +under other x:Input-Output windows. This is not the same as preserving the +contents of a window for you. You may get better visual appeal if +transient windows (for example, pop-up menus) request that the system +preserve the screen contents under them, so the temporarily obscured +applications do not have to repaint. +
+You can set the save-under flag to True or False (default). If +save-under is True, the X server is advised that, when this window is +mapped, saving the contents of windows it obscures would be beneficial. +
The event mask defines which events the client is interested in for this +x:Input-Output or x:Input-Only window (or, for some event types, +inferiors of this window). The event mask is the bitwise inclusive OR +of zero or more of the valid event mask bits. You can specify that no +maskable events are reported by setting x:No-Event-Mask (default). +
+The following table lists the event mask constants you can pass to the +event-mask argument and the circumstances in which you would want to +specify the event mask: +
+| Event Mask | Circumstances |
| x:No-Event-Mask | No events wanted |
| x:Key-Press-Mask | Keyboard down events wanted |
| x:Key-Release-Mask | Keyboard up events wanted |
| x:Button-Press-Mask | Pointer button down events wanted |
| x:Button-Release-Mask | Pointer button up events wanted |
| x:Enter-Window-Mask | Pointer window entry events wanted |
| x:Leave-Window-Mask | Pointer window leave events wanted |
| x:Pointer-Motion-Mask | Pointer motion events wanted |
| x:Pointer-Motion-Hint-Mask | If x:Pointer-Motion-Hint-Mask is selected in combination with one or +more motion-masks, the X server is free to send only one x:Motion-Notify +event (with the is_hint member of the X:Pointer-Moved-Event structure +set to x:Notify-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 calls X:Query-Pointer or X:Get-Motion-Events. The server +still may send x:Motion-Notify events without is_hint set to +x:Notify-Hint. |
| x:Button1-Motion-Mask | Pointer motion while button 1 down |
| x:Button2-Motion-Mask | Pointer motion while button 2 down |
| x:Button3-Motion-Mask | Pointer motion while button 3 down |
| x:Button4-Motion-Mask | Pointer motion while button 4 down |
| x:Button5-Motion-Mask | Pointer motion while button 5 down |
| x:Button-Motion-Mask | Pointer motion while any button down |
| x:Keymap-State-Mask | Keyboard state wanted at window entry and focus in |
| x:Exposure-Mask | Any exposure wanted |
| x:Visibility-Change-Mask | Any change in visibility wanted |
| x:Structure-Notify-Mask | Any change in window structure wanted |
| x:Resize-Redirect-Mask | Redirect resize of this window |
| x:Substructure-Notify-Mask | Substructure notification wanted |
| x:Substructure-Redirect-Mask | Redirect structure requests on children |
| x:Focus-Change-Mask | Any change in input focus wanted |
| x:Property-Change-Mask | Any change in property wanted |
| x:Colormap-Change–Mask | Any change in colormap wanted |
| x:Owner-Grab-Button–Mask | Automatic grabs should activate with owner_events set to True |
The do-not-propagate-mask attribute defines which events should not be +propagated to ancestor windows when no client has the event type +selected in this x:Input-Output or x:Input-Only window. The +do-not-propagate-mask is the bitwise inclusive OR of zero or more of the +following masks: x:Key-Press, x:Key-Release, x:Button-Press, +x:Button-Release, x:Pointer-Motion, x:Button1Motion, x:Button2Motion, +x:Button3Motion, x:Button4Motion, x:Button5Motion, and x:Button-Motion. +You can specify that all events are propagated by setting +x:No-Event-Mask (default). +
The colormap attribute specifies which colormap best reflects the true +colors of the x:Input-Output window. The colormap must have the same +visual type as the window. X servers capable of supporting multiple +hardware colormaps can use this information, and window managers can use +it for calls to X:Install-Colormap. You can set the colormap attribute +to a colormap or to x:Copy-From-Parent (default). +
+If you set the colormap to x:Copy-From-Parent, the parent window’s +colormap is copied and used by its child. However, the child window +must have the same visual type as the parent. The parent window must +not have a colormap of x:None. The colormap is copied by sharing the +colormap object between the child and parent, not by making a complete +copy of the colormap contents. Subsequent changes to the parent +window’s colormap attribute do not affect the child window. +
The cursor attribute specifies which cursor is to be used when the +pointer is in the x:Input-Output or x:Input-Only window. You can set +the cursor to a cursor or x:None (default). +
+If you set the cursor to x:None, the parent’s cursor is used when the +pointer is in the x:Input-Output or x:Input-Only window, and any change +in the parent’s cursor will cause an immediate change in the displayed +cursor. On the root window, the default cursor is restored. +
Returns a list of the components specified by field-names for the
+specified window. Allowable field-names are a subset of
+those for x:window-set!:
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Returns the (string or list of numbers) value of property of +window. +
Removes and returns the (string or list of numbers) value of +property of window. +
Returns a list of the properties (strings) defined for window. +
In X parlance, a window which is hidden even when not obscured by other +windows is unmapped; one which + + + + +shows is mapped. It is an unfortunate name-collision with Scheme, +and is ingrained in the attribute names. +
+Maps the window and all of its subwindows that have had map +requests. Mapping a window that has an unmapped ancestor does not +display the window but marks it as eligible for display when the +ancestor becomes mapped. Such a window is called unviewable. When all +its ancestors are mapped, the window becomes viewable and will be +visible on the screen if it is not obscured by another window. This +function has no effect if the window is already mapped. +
+If the override-redirect of the window is False and if some other client
+has selected x:Substructure-Redirect-Mask on the parent window, then the X
+server generates a MapRequest event, and the x:map-window
+function does not map the window. Otherwise, the window is
+mapped, and the X server generates a MapNotify event.
+
If the window becomes viewable and no earlier contents for it are +remembered, the X server tiles the window with its background. If +the window’s background is undefined, the existing screen contents are +not altered, and the X server generates zero or more x:Expose events. If +backing-store was maintained while the window was unmapped, no +x:Expose events are generated. If 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. +
+If the window is an Input-Output window, x:map-window generates
+x:Expose events on each Input-Output window that it causes to be displayed.
+If the client maps and paints the window and if the client begins
+processing events, the window is painted twice. To avoid this, first
+ask for x:Expose events and then map the window, so the client processes
+input events as usual. The event list will include x:Expose for each
+window that has appeared on the screen. The client’s normal response to
+an x:Expose event should be to repaint the window. This method usually
+leads to simpler programs and to proper interaction with window
+managers.
+
Maps all subwindows of a specified window in top-to-bottom +stacking order. The X server generates x:Expose events on each newly +displayed window. This may be much more efficient than mapping many +windows one at a time because the server needs to perform much of the +work only once, for all of the windows, rather than for each window. +
Unmaps the specified window and causes the X server to generate an
+UnmapNotify event. If the specified window is already unmapped,
+x:unmap-window has no effect. Normal exposure processing on
+formerly obscured windows is performed. Any child window will no longer
+be visible until another map call is made on the parent. In other
+words, the subwindows are still mapped but are not visible until the
+parent is mapped. Unmapping a window will generate x:Expose events
+on windows that were formerly obscured by it.
+
Unmaps all subwindows for the specified window in bottom-to-top +stacking order. It causes the X server to generate an UnmapNotify event +on each subwindow and x:Expose events on formerly obscured windows. Using +this function is much more efficient than unmapping multiple windows one +at a time because the server needs to perform much of the work only +once, for all of the windows, rather than for each window. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Most attributes of graphics operations are stored in GCs. These +include line width, line style, plane mask, foreground, background, +tile, stipple, clipping region, end style, join style, and so on. +Graphics operations (for example, drawing lines) use these values to +determine the actual drawing operation. +
+Creates and returns graphics context. The graphics context can be used +with any destination drawable having the same root and depth as the +specified drawable. +
Changes the components specified by field-names for the specified
+graphics-context. The restrictions are the same as for
+x:create-gc. The order in which components are verified and
+altered is server dependent. If an error occurs, a subset of the
+components may have been altered.
+
Copies the components specified by field-names from +gcontext-src to gcontext-dst. Gcontext-src and +gcontext-dst must have the same root and depth. +
Returns a list of the components specified by field-names … +from the specified graphics-context. +
Both x:create-gc and x:change-gc take one argument
+followed by pairs of arguments, where the first is one of the
+property-name symbols (or its top-level value) listed below; and the
+second is the value to associate with that property.
+
The function attributes of a GC are used when you update a section of a +drawable (the destination) with bits from somewhere else (the source). +The function in a GC defines how the new destination bits are to be +computed from the source bits and the old destination bits. x:G-Xcopy is +typically the most useful because it will work on a color display, but +special applications may use other functions, particularly in concert +with particular planes of a color display. The 16 functions are: +
++x:G-Xclear 0 +x:G-Xand (AND src dst) +x:G-Xand-Reverse (AND src (NOT dst)) +x:G-Xcopy src +x:G-Xand-Inverted (AND (NOT src) dst) +x:G-Xnoop dst +x:G-Xxor (XOR src dst) +x:G-Xor (OR src dst) +x:G-Xnor (AND (NOT src) (NOT dst)) +x:G-Xequiv (XOR (NOT src) dst) +x:G-Xinvert (NOT dst) +x:G-Xor-Reverse (OR src (NOT dst)) +x:G-Xcopy-Inverted (NOT src) +x:G-Xor-Inverted (OR (NOT src) dst) +x:G-Xnand (OR (NOT src) (NOT dst)) +x:G-Xset 1 + |
Many graphics operations depend on either pixel values or planes in a +GC. The planes attribute is an integer which specifies which planes of +the destination are to be modified, one bit per plane. A monochrome +display has only one plane and will be the least significant bit of the +integer. As planes are added to the display hardware, they will occupy +more significant bits in the plane mask. +
+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. x:All-Planes can be
+used to refer to all planes of the screen simultaneously. The result is
+computed by the following:
+
(OR (AND (FUNC src dst) plane-mask) (AND dst (NOT plane-mask))) + |
Range checking is not performed on a plane-mask value. It is simply +truncated to the appropriate number of bits. +
Range checking is not performed on the values for foreground or +background. They are simply truncated to the appropriate number of +bits. +
+Note that foreground and background are not initialized to any values +likely to be useful in a window. +
The line-width is measured in pixels and either can be greater than or +equal to one (wide line) or can be the special value zero (thin line). +
+Thin lines (zero line-width) are one-pixel-wide lines drawn using an +unspecified, device-dependent algorithm. There are only two constraints +on this algorithm. +
+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-style and +join-style. It is recommended that this property be true for thin +lines, but this is not required. A line-width of zero may differ from a +line-width of one in which pixels are drawn. This permits the use of +many manufacturers’ line drawing hardware, which may run many times +faster than the more precisely specified wide lines. +
+In general, drawing a thin line will be faster than drawing a wide line +of width one. However, because of their different drawing algorithms, +thin lines may not mix well aesthetically with wide lines. If it is +desirable to obtain precise and uniform results across all displays, a +client should always use a line-width of one rather than a linewidth of +zero. +
The line-style defines which sections of a line are drawn: +
+The full path of the line is drawn. +
The full path of the line is drawn, but the even dashes are filled +differently from the odd dashes (see fill-style) with x:Cap-Butt style used +where even and odd dashes meet. +
Only the even dashes are drawn, and cap-style applies to all internal +ends of the individual dashes, except x:Cap-Not-Last is treated as x:Cap-Butt. +
The cap-style defines how the endpoints of a path are drawn: +
+This is equivalent to x:Cap-Butt except that for a line-width of zero the +final endpoint is not drawn. +
The line is square at the endpoint (perpendicular to the slope of the +line) with no projection beyond. +
The line has a circular arc with the diameter equal to the line-width, +centered on the endpoint. (This is equivalent to x:Cap-Butt for line-width +of zero). +
The line is square at the end, but the path continues beyond the +endpoint for a distance equal to half the line-width. (This is +equivalent to x:Cap-Butt for line-width of zero). +
The join-style defines how corners are drawn for wide lines: +
+The outer edges of two lines extend to meet at an angle. However, if +the angle is less than 11 degrees, then a x:Join-Bevel join-style is used +instead. +
The corner is a circular arc with the diameter equal to the +line-width, centered on the x:Join-point. +
The corner has x:Cap-Butt endpoint styles with the triangular notch filled. +
The fill-style defines the contents of the source for line, text, and +fill requests. For all text and fill requests (for example, +X:Draw-Text, X:Fill-Rectangle, X:Fill-Polygon, and X:Fill-Arc); for line +requests with linestyle x:Line-Solid (for example, X:Draw-Line, +X:Draw-Segments, X:Draw-Rectangle, X:Draw-Arc); and for the even dashes +for line requests with line-style x:Line-On-Off-Dash or +x:Line-Double-Dash, the following apply: +
+Foreground +
Tile +
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 +
Foreground masked by stipple +
When drawing lines with line-style x:Line-Double-Dash, the odd dashes +are controlled by the fill-style in the following manner: +
+Background +
Same as for even dashes +
Same as for even dashes +
Background masked by stipple +
The fill-rule defines what pixels are inside (drawn) for paths given in +X:Fill-Polygon requests and can be set to x:Even-Odd-Rule or +x:Winding-Rule. +
+A point is inside if an infinite ray with the point as +origin crosses the path an odd number of times. +
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 +to right as observed from the point. A counterclockwise segment is one +that crosses the ray from right to left as observed from the point. The +case where a directed line segment is coincident with the ray is +uninteresting because you can simply choose a different ray that is not +coincident with a segment. +
+For both x:Even-Odd-Rule and x:Winding-Rule, 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 on a horizontal edge are +a special case and are inside if and only if the polygon interior is +immediately below (y increasing direction). +
The tile/stipple represents an infinite two-dimensional plane, with the +tile/stipple replicated in all dimensions. +
+The tile pixmap must have the same root and depth as the GC, or an error +results. The stipple pixmap must have depth one and must have the same +root as the GC, or an error results. For stipple operations where the +fill-style is x:Fill-Stippled but not x:Fill-Opaque-Stippled, the +stipple pattern is tiled in a single plane and acts as an additional +clip mask to be ANDed with the clip-mask. Although some sizes may be +faster to use than others, any size pixmap can be used for tiling or +stippling. +
When the tile/stipple plane is superimposed on a drawable for use in a +graphics operation, the upper-left corner of some instance of the +tile/stipple is at the coordinates within the drawable specified by the +tile/stipple origin. The tile/stipple origin is interpreted relative to +the origin of whatever destination drawable is specified in a graphics +request. +
You can set the subwindow-mode to x:Clip-By-Children or +x:Include-Inferiors. +
Both source and destination windows are additionally clipped by all +viewable Input-Output children. +
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
+x:Include-Inferiors on a window of one depth with mapped
+inferiors of differing depth is not illegal, but the semantics are
+undefined by the core protocol.
+
The graphics-exposure flag controls x:Graphics-Expose event generation +for X:Copy-Area and X:Copy-Plane requests (and any similar requests +defined by extensions). +
The clip-mask origin is interpreted relative to the origin of whatever +destination drawable is specified in a graphics request. +
The clip-mask restricts writes to the destination drawable. If the
+clip-mask is set to a pixmap, it must have depth one and have the same
+root as the GC, or an error results. If clip-mask is set to
+
+
+x:None, the pixels are always drawn regardless of the clip origin.
+The clip-mask also can be set by calling X:Set-Region. Only
+pixels where the clip-mask has a bit set to 1 are drawn. Pixels are not
+drawn outside the area covered by the clip-mask or where the clip-mask
+has a bit set to 0. The clip-mask 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.
+
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 elements combined with a +join-style but is reset to the dash-offset between each sequence of +joined lines. +
+The unit of measure for dashes is the same for the ordinary +coordinate system. Ideally, a dash length is measured along +the slope of the line, but implementations are only required +to match this ideal for horizontal and vertical lines. +Failing the ideal semantics, it is suggested that the length +be measured along the major axis of the line. The major +axis is defined as the x axis for lines drawn at an angle of +between -45 and +45 degrees or between 135 and 225 degrees +from the x axis. For all other lines, the major axis is the +y axis. +
There must be at least one element in the specified dash-list. +The initial and alternating elements (second, fourth, and so on) of the +dash-list are the even dashes, and the others are the odd dashes. +Each element specifies a dash length in pixels. All of the elements +must be nonzero. Specifying an odd-length list is equivalent to +specifying the same list concatenated with itself to produce an +even-length list. +
The arc-mode controls filling in the X:Fill-Arcs function and can be set +to x:Arc-Pie-Slice or x:Arc-Chord. +
The arcs are pie-slice filled. +
The arcs are chord filled. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
X provides a set of standard cursor shapes in a special font named + +cursor. Applications are encouraged to use this interface for +their cursors because the font can be customized for the individual +display type. The shape argument specifies which glyph of the standard +fonts to use. +
+The hotspot comes from the information stored in the cursor font. The +initial colors of a cursor are a black foreground and a white background +(see X:Recolor-Cursor). The names of all cursor shapes are defined with +the prefix XC: in ‘x11.scm’. +
+Creates a cursor from the source and mask bitmaps obtained from the +specified font glyphs. The integer source-char must be a defined +glyph in source-font. The integer mask-char must be a +defined glyph in mask-font. The origins of the source-char +and mask-char glyphs are positioned coincidently and define the +hotspot. The source-char and mask-char need not have the +same bounding box metrics, and there is no restriction on the placement +of the hotspot relative to the bounding boxes. +
+If mask-font and mask-char are #f, all pixels of the source +are displayed. +
+mask-pixmap must be the same size as the pixmap defined by the +source-pixmap argument. The foreground and background RGB values +must be specified using foreground-color and +background-color, even if the X server only has a x:Static-Gray or +x:Gray-Scale screen. The hotspot must be a point within the +source-pixmap. +
+X:Create-Cursor creates and returns a cursor. The
+foreground-color is used for the pixels set to 1 in the source,
+and the background-color is used for the pixels set to 0. Both
+source and mask must have depth one but can have any root. The
+mask-pixmap defines the shape of the cursor. The pixels set to 1
+in mask-pixmap define which source pixels are displayed, and the
+pixels set to 0 define which pixels are ignored.
+
If mask-pixmap is #f, all pixels of the source are displayed. +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
A colormap maps pixel values to RGB color space values. +
+window specifies the window on whose screen you want to create a
+colormap. visual specifies a visual type supported on the screen.
+alloc-policy Specifies the colormap entries to be allocated. You
+can pass X:Alloc-None or X:Alloc-All.
+
The X:Create-Colormap function creates and returns a colormap of
+the specified visual type for the screen on which window
+resides. Note that window is used only to determine the screen.
+
The initial values of the colormap entries are undefined. +
+The entries have defined values, but those values are specific to +visual and are not defined by X. The alloc-policy must be +‘X:Alloc-None’. +
+For the other visual classes, if alloc-policy is +‘X:Alloc-None’, the colormap initially has no allocated entries, +and clients can allocate them. +
+If alloc-policy is ‘X:Alloc-All’, the entire colormap is +allocated writable. The initial values of all allocated entries are +undefined. +
+The effect is as if an XAllocColorCells call returned all pixel
+values from zero to N - 1, where N is the colormap entries value in
+visual.
+
The effect is as if an XAllocColorPlanes call 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.
+
To create a new colormap when the allocation out of a previously +shared colormap has failed because of resource exhaustion, use: +
+Creates and returns a colormap of the same visual type and for the same +screen as the specified colormap. It also moves all of the +client’s existing allocation from the specified colormap to the +new colormap with their color values intact and their read-only or +writable characteristics intact and frees those entries in the specified +colormap. Color values in other entries in the new colormap are +undefined. If the specified colormap was created by the client with +alloc set to ‘X:Alloc-All’, the new colormap is also created with +‘X:Alloc-All’, all color values for all entries are copied from the +specified colormap, and then all entries in the specified +colormap are freed. If the specified colormap was not +created by the client with ‘X:Alloc-All’, the allocations to be moved +are all those pixels and planes that have been allocated by the client +and that have not been freed since they were allocated. +
+A colormap maps pixel values to elements of the RGB +datatype. An RGB is a list or vector of 3 integers, describing +the red, green, and blue intensities respectively. The integers are in +the range 0 - 65535. +
+The X:Alloc-Color-Cells function allocates read/write color
+cells. The number of colors, ncolors must be positive and the
+number of planes, nplanes nonnegative. If ncolors and
+nplanes are requested, then ncolors pixels and nplane plane masks
+are returned. No mask will have any bits set to 1 in common with any
+other mask or with any of the pixels. By ORing together each pixel with
+zero or more masks, ncolors * 2^nplanes distinct pixels can
+be produced. All of these are allocated writable by the request.
+
Each mask has exactly one bit set to 1. If contiguous? is +non-false and if all masks are ORed together, a single contiguous set of +bits set to 1 is formed. +
Each mask has exactly three bits set to 1. If contiguous? is +non-false and if all masks are ORed together, three contiguous sets of +bits set to 1 (one within each pixel subfield) is formed. +
The RGB values of the allocated entries are undefined.
+X:Alloc-Color-Cells returns a list of two uniform arrays if it
+succeeded or #f if it failed. The first array has the pixels allocated
+and the second has the plane-masks.
+
The specified ncolors must be positive; and rgb a list or +vector of 3 nonnegative integers. If ncolors colors, nreds +reds, ngreens greens, and nblues blues are requested, +ncolors pixels are returned; and the masks have nreds, +ngreens, and nblues bits set to 1, respectively. If +contiguous? is non-false, each mask will have a contiguous set of +bits set to 1. No mask will have any bits set to 1 in common with any +other mask or with any of the pixels. +
+Each mask will lie within the corresponding pixel subfield. By ORing +together subsets of masks with each pixel value, ncolors * +2(nreds+ngreens+nblues) distinct pixel values can be +produced. All of these are allocated by the request. However, in the +colormap, there are only ncolors * 2^nreds independent red +entries, ncolors * 2^ngreens independent green entries, and +ncolors * 2^nblues independent blue entries. +
+X:Alloc-Color-Cells returns a list if it succeeded or #f if it
+failed. The first element of the list has an array of the pixels
+allocated. The second, third, and fourth elements are the red, green,
+and blue plane-masks.
+
Frees the cells represented by pixels whose values are in the
+pixels unsigned-integer uniform-vector. The planes argument
+should not have any bits set to 1 in common with any of the pixels. The
+set of all pixels is produced by ORing together subsets of the
+planes argument with the pixels. The request frees all of these
+pixels that were allocated by the client. Note that freeing an
+individual pixel obtained from X:Alloc-Colormap-Cells with a
+planes argument 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 freed by all clients, and if a client
+allocates the same read-only entry multiple times, it must free the
+entry that many times before the entry is actually freed.
+
All specified pixels that are allocated by the client in the
+colormap are freed, even if one or more pixels produce an error.
+It is an error 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 (by passing
+‘x:Alloc-All’ to X:Create-Colormap). If more than one pixel
+is in error, the one that gets reported is arbitrary.
+
rgb is a list or vector of 3 integers, describing the red, green, +and blue intensities respectively; or an integer ‘#xrrggbb’, +packing red, green and blue intensities in the range 0 - 255. +
+The case-insensitive string color_name specifies the name of a +color (for example, ‘red’) +
+X:Colormap-Find-Color allocates a read-only colormap entry
+corresponding to the closest RGB value supported by the hardware.
+X:Colormap-Find-Color returns the pixel value of the color
+closest to the specified RGB or color_name elements
+supported by the hardware, if successful; otherwise
+X:Colormap-Find-Color returns #f.
+
Multiple clients that request the same effective RGB value can +be assigned the same read-only entry, thus allowing entries to be +shared. When the last client deallocates a shared cell, it is +deallocated. +
+Returns a list of 3 integers, describing the red, green, +and blue intensities respectively of the colormap entry of the +cell indexed by pixel. +
+The integer pixel must be a valid index into colormap. +
rgb is a list or vector of 3 integers, describing the red, green, +and blue intensities respectively; or an integer ‘#xrrggbb’, +packing red, green and blue intensities in the range 0 - 255. +
+The case-insensitive string color_name specifies the name of a +color (for example, ‘red’) +
+The integer pixel must be a valid index into colormap. +
+X:Color-Set! changes the colormap entry of the read/write
+cell indexed by pixel. If the colormap is an installed map
+for its screen, the changes are visible immediately.
+
Installs the specified colormap for its associated screen. All +windows associated with colormap immediately display with true +colors. A colormap is associated with a window when the window is +created or its attributes changed. +
+If the specified colormap is not already an installed colormap, the X +server generates a ColormapNotify event on each window that has that +colormap. +
+| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
Flushes the output buffer. Some client applications need not use this +function because the output buffer is automatically flushed as needed by +calls to X:Pending, X:Next-Event, and X:Window-Event. Events generated +by the server may be enqueued into the library’s event queue. +
+Forces sending of GC component changes. +
+Xlib usually defers sending changes to the components of a GC to the +server until a graphics function is actually called with that GC. This +permits batching of component changes into a single server request. In +some circumstances, however, it may be necessary for the client to +explicitly force sending the changes to the server. An example might be +when a protocol extension uses the GC indirectly, in such a way that the +extension interface cannot know what GC will be used. +
Paints a rectangular area in the specified window according to the +specified dimensions with the window’s background pixel or pixmap. +The subwindow-mode effectively is ‘x:Clip-By-Children’. 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 clipped by any children is filled with this tile. +If the window has background x:None, the contents of the +window are not changed. In either case, if expose? is True, +one or more x:Expose events are generated for regions of the rectangle +that are either visible or are being retained in a backing store. If +you specify a window whose class is x:Input-Only, an error +results. +
Position specifies coordinates relative to the origin of +drawable of the origin of the first character to be drawn. +
+x:draw-string draws the characters of string, starting at
+position.
+
Position specifies coordinates relative to the origin of +drawable of the origin of the first character to be drawn. +
+x:image-string draws the characters and background of
+string, starting at position.
+
Position … specifies coordinates of the point to be drawn. +
+(x, y) … specifies coordinates of the point to be +drawn. +
+point-array is a uniform short array of rank 2, whose rightmost +index spans a range of 2. +
+The X:Draw-Points procedure uses the foreground pixel and
+function components of the gc to draw points into drawable
+at the positions (relative to the origin of drawable) specified.
+
X:Draw-Points uses these gc components: function,
+planemask, foreground, subwindow-mode, clip-x-origin, clip-y-origin, and
+clip-mask.
+
Pos1, pos2, … specify coordinates to be connected by +segments. +
+(x1, y1), (x2, y2) … specify coordinates +to be connected by segments. +
+point-array is a uniform short array of rank 2, whose rightmost +index spans a range of 2. +
+The X:Draw-Segments procedure uses the components of the
+specified gc to draw multiple unconnected lines between disjoint
+adjacent pair of points passed as arguments. It draws the segments in
+order and does not perform joining at coincident endpoints. For any
+given line, X:Draw-Segments does not draw a pixel more than once.
+If thin (zero line-width) segments intersect, the intersecting pixels
+are drawn multiple times. If wide segments intersect, the intersecting
+pixels are drawn only once, as though the entire PolyLine protocol
+request were a single, filled shape. X:Draw-Segments treats all
+coordinates as relative to the origin of drawable.
+
X:Draw-Segments uses these gc components: function,
+plane-mask, line-width, line-style, cap-style, fill-style,
+subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask, join-style.
+It also use these gc mode-dependent components: foreground,
+background, tile, stipple, tilestipple-x-origin, tile-stipple-y-origin,
+dash-offset, and dash-list.
+
Pos1, pos2, … specify coordinates to be connected by +lines. +
+(x1, y1), (x2, y2) … specify coordinates +to be connected by lines. +
+point-array is a uniform short array of rank 2, whose rightmost +index spans a range of 2. +
+The X:Draw-Lines procedure uses the components of the specified
+gc to draw lines between each adjacent pair of points passed as
+arguments. It draws the lines in order. The lines join correctly at
+all intermediate points, and if the first and last points coincide, the
+first and last lines also join correctly. For any given line,
+X:Draw-Lines does not draw a pixel more than once. 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 protocol request were a single,
+filled shape. X:Draw-Lines treats all coordinates as relative to
+the origin of drawable.
+
X:Draw-Lines uses these gc components: function,
+plane-mask, line-width, line-style, cap-style, fill-style,
+subwindow-mode, clip-x-origin, clip-y-origin, and clip-mask, join-style.
+It also use these gc mode-dependent components: foreground,
+background, tile, stipple, tilestipple-x-origin, tile-stipple-y-origin,
+dash-offset, and dash-list.
+
Pos1, pos2, … specify coordinates of the border path. +
+(x1, y1), (x2, y2) … specify coordinates +of the border path. +
+point-array is a uniform short array of rank 2, whose rightmost +index spans a range of 2. +
+The path is closed automatically if the last point in the list or +point-array does not coincide with the first point. +
+The X:Fill-Polygon procedure uses the components of the specified
+gc to fill the region closed by the specified path.
+X:Fill-Polygon does not draw a pixel of the region more than
+once. X:Fill-Polygon treats all coordinates as relative to the
+origin of drawable.
+
X:Fill-Polygon uses these gc components: function,
+planemask, fill-style, fill-rule, subwindow-mode, clip-x-origin,
+clip-y-origin, and clip-mask. It also use these gc mode-dependent
+components: foreground, background, tile, stipple,
+tile-stipple-x-origin, and tile-stipple-y-origin.
+
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
These three status routines always return immediately if there are +events already in the queue. +
+Returns the length of the event queue for the connected display. +Note that there may be more events that have not been read into the +queue yet (see X:Events-Queued). +
Returns the number of events that have been received from the X server +but have not been removed from the event queue. +
Returns the number of events already in the queue if the number is
+nonzero. If there are no events in the queue, X:Events-Queued
+attempts to read more events out of the application’s connection without
+flushing the output buffer and returns the number read.
+
Both of these routines return an object of type event. +
+Removes and returns the first event from the event queue. If the event
+queue is empty, X:Next-Event flushes the output buffer and blocks
+until an event is received.
+
Returns the first event from the event queue, but it does not remove the
+event from the queue. If the queue is empty, X:Peek-Event
+flushes the output buffer and blocks until an event is received.
+
Each event object has fields dependent on its sub-type. +
+| window | The window on which event was generated and is referred to as the +event window. |
| root | is the event window’s root window. |
| subwindow | If the source window is an inferior of the event window, the +subwindow is the child of the event window that is the source +window or the child of the event window that is an ancestor of the +source window. Otherwise, ‘None’. |
| X-event:type | An integer: x:Key-Press, x:Key-Release, +x:Button-Press, x:Button-Release, x:Motion-Notify, +x:Enter-Notify, x:Leave-Notify, x:Focus-In, +x:Focus-Out, x:Keymap-Notify, x:Expose, +x:Graphics-Expose, x:No-Expose, x:Visibility-Notify, +x:Create-Notify, x:Destroy-Notify, x:Unmap-Notify, +x:Map-Notify, x:Map-Request, x:Reparent-Notify, +x:Configure-Notify, x:Configure-Request, +x:Gravity-Notify, x:Resize-Request, +x:Circulate-Notify, x:Circulate-Request, +x:Property-Notify, x:Selection-Clear, +x:Selection-Request, x:Selection-Notify, +x:Colormap-Notify, x:Client-Message, or +x:Mapping-Notify. |
| X-event:serial | The serial number of the protocol request that generated the event. |
| X-event:send-event | Boolean that indicates whether the event was sent by a different client. |
| X-event:time | The time when the event was generated expressed in milliseconds. |
| X-event:x | |
| X-event:y | For window entry/exit events the x and y members are set to
+the coordinates of the pointer position in the event window. This
+position is always the pointer’s final position, not its initial
+position. If the event window is on the same screen as the root window,
+x and y are the pointer coordinates relative to the event
+window’s origin. Otherwise, x and y are set to zero.
+
+ For expose events The x and y members are set to the +coordinates relative to the drawable’s origin and indicate the +upper-left corner of the rectangle. + +For configure, create, gravity, and reparent events the x and +y members are set to the window’s coordinates relative to the +parent window’s origin and indicate the position of the upper-left +outside corner of the created window. + |
| X-event:x-root | |
| X-event:y-root | The pointer’s coordinates relative to the root window’s origin at the +time of the event. |
| X-event:state | For keyboard, pointer and window entry/exit events, the state member is
+set to indicate the logical state of the pointer buttons and modifier
+keys just prior to the event, which is the bitwise inclusive OR of
+one or more of the button or modifier key masks: x:Button1-Mask,
+x:Button2-Mask, x:Button3-Mask, x:Button4-Mask,
+x:Button5-Mask, x:Shift-Mask, x:Lock-Mask,
+x:Control-Mask, x:Mod1-Mask, x:Mod2-Mask,
+x:Mod3-Mask, x:Mod4-Mask, and x:Mod5-Mask.
+
+ For visibility events, the state of the window’s visibility: +x:Visibility-Unobscured, x:Visibility-Partially-Obscured, or +x:Visibility-Fully-Obscured. + +For colormap events, indicates whether the colormap is installed or +uninstalled: x:Colormap-Installed or x:Colormap-Uninstalled. + +For property events, indicates whether the property was changed to a new +value or deleted: x:Property-New-Value or x:Property-Delete. + |
| X-event:keycode | An integer that represents a physical key on the keyboard. |
| X-event:same-screen | Indicates whether the event window is on the same screen as the root +window. If #t, the event and root windows are on the same screen. If +#f, the event and root windows are not on the same screen. |
| X-event:button | The pointer button that changed state; can be the x:Button1, +x:Button2, x:Button3, x:Button4, or x:Button5 +value. |
| X-event:is-hint | Detail of motion-notify events: x:Notify-Normal or +x:Notify-Hint. |
| X-event:mode | Indicates whether the event is a normal event, pseudo-motion event +when a grab activates, or a pseudo-motion event when a grab deactivates: +x:Notify-Normal, x:Notify-Grab, or x:Notify-Ungrab. |
| X-event:detail | Indicates the notification detail: x:Notify-Ancestor, +x:Notify-Virtual, x:Notify-Inferior, +x:Notify-Nonlinear, or x:Notify-Nonlinear-Virtual. |
| X-event:focus | If the event window is the focus window or an inferior of the focus +window, #t; otherwise #f. |
| X-event:width | |
| X-event:height | The size (extent) of the rectangle. |
| X-event:count | For mapping events is the number of keycodes altered.
+
+ For expose events Is the number of Expose or GraphicsExpose events that +are to follow. If count is zero, no more Expose events follow for this +window. However, if count is nonzero, at least that number of Expose +events (and possibly more) follow for this window. Simple applications +that do not want to optimize redisplay by distinguishing between +subareas of its window can just ignore all Expose events with nonzero +counts and perform full redisplays on events with zero counts. + |
| X-event:major-code | The major_code member is set to the graphics request initiated by the +client and can be either X_CopyArea or X_CopyPlane. If it is +X_CopyArea, a call to XCopyArea initiated the request. If it is +X_CopyPlane, a call to XCopyPlane initiated the request. |
| X-event:minor-code | Not currently used. |
| X-event:border-width | For configure events, the width of the window’s border, in pixels. |
| X-event:override-redirect | The override-redirect attribute of the window. Window manager clients +normally should ignore this window if it is #t. |
| X-event:from-configure | True if the event was generated as a result of a resizing of the +window’s parent when the window itself had a win-gravity of +x:Unmap-Gravity. |
| X-event:value-mask | Indicates which components were specified in the ConfigureWindow +protocol request. The corresponding values are reported as given in the +request. The remaining values are filled in from the current geometry +of the window, except in the case of above (sibling) and detail +(stack-mode), which are reported as None and Above, respectively, if +they are not given in the request. |
| X-event:place | The window’s position after the restack occurs and is either +x:Place-On-Top or x:Place-On-Bottom. If it is x:Place-On-Top, the +window is now on top of all siblings. If it is x:Place-On-Bottom, the +window is now below all siblings. |
| X-event:new | indicate whether the colormap for the specified window was changed or +installed or uninstalled and can be True or False. If it is True, the +colormap was changed. If it is False, the colormap was installed or +uninstalled. |
| X-event:format | Is 8, 16, or 32 and specifies whether the data should be viewed as a +list of bytes, shorts, or longs |
| X-event:request | Indicates the kind of mapping change that occurred and can be +x:Mapping-Modifier, x:Mapping-Keyboard, or +x:Mapping-Pointer. If it is x:Mapping-Modifier, the +modifier mapping was changed. If it is x:Mapping-Keyboard, the +keyboard mapping was changed. If it is x:Mapping-Pointer, the +pointer button mapping was changed. |
| X-event:first-keycode | The X-event:first-keycode is set only if the X-event:request was set to +x:Mapping-Keyboard. The number in X-event:first-keycode +represents the first number in the range of the altered mapping, and +X-event:count represents the number of keycodes altered. |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Procedure and Macro Index | + | |
| Variable Index | + | |
| Concept Index | + |
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | H + +X + + |
|---|
| Jump to: | H + +X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | X + + |
|---|
| Jump to: | X + + |
|---|
| [ < ] | +[ > ] | ++ | [ << ] | +[ Up ] | +[ >> ] | ++ | + | + | + | [Top] | +[Contents] | +[Index] | +[ ? ] | +
| Jump to: | C + +D + +M + +N + +R + +U + +V + +X + + |
|---|
| Jump to: | C + +D + +M + +N + +R + +U + +V + +X + + |
|---|
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
| [Top] | +[Contents] | +[Index] | +[ ? ] | +
+ This document was generated by iwamatsu on March 3, 2010 using texi2html 1.82. +
++ The buttons in the navigation panels have the following meaning: +
+| Button | +Name | +Go to | +From 1.2.3 go to | +
|---|---|---|---|
| [ < ] | +Back | +Previous section in reading order | +1.2.2 | +
| [ > ] | +Forward | +Next section in reading order | +1.2.4 | +
| [ << ] | +FastBack | +Beginning of this chapter or previous chapter | +1 | +
| [ Up ] | +Up | +Up section | +1.2 | +
| [ >> ] | +FastForward | +Next chapter | +2 | +
| [Top] | +Top | +Cover (top) of document | ++ |
| [Contents] | +Contents | +Table of contents | ++ |
| [Index] | +Index | +Index | ++ |
| [ ? ] | +About | +About (help) | ++ |
+ where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure: +
+ +
+
+ This document was generated by iwamatsu on March 3, 2010 using texi2html 1.82.
+
+
+
+