| [Top] | [Contents] | [Index] | [ ? ] |
This manual documents the X - SCM Language X Interface. The most recent information about SCM can be found on SCM's WWW home page:
Copyright (C) 1990-1999 Free Software Foundation
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 | ||
| Procedure and Macro Index |
| [ < ] | [ > ] | [ << ] | [ 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:
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] | [ ? ] |
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.
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.
A display consists of one or more Screens. Each screen has a root-window, default-graphics-context, and colormap.
x:open-display
function. Use this screen number in applications which will use only a
single screen.
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.
The Visual type describes possible colormap depths and arrangements.
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.
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.
| [ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |
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.
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.
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.
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.
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
If a sibling and a stack-mode are specified, the window is restacked as follows:
x:Above
x:Below
x:Top-If
x:Bottom-If
x:Opposite
If a stack-mode is specified but no sibling is specified, the window is restacked as follows:
x:Above
x:Below
x:Top-If
x:Bottom-If
x:Opposite
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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.
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.
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.
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 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 |
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.
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.
x:window-set!:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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.
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.
| [ < ] | [ > ] | [ << ] | [ 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.
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.
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.
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.
Note that foreground and background are not initialized to any values likely to be useful in a window.
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 cap-style defines how the endpoints of a path are drawn:
The join-style defines how corners are drawn for wide lines:
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:
When drawing lines with line-style x:Line-Double-Dash, the odd dashes are controlled by the fill-style in the following manner:
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 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.
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.
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.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A colormap maps pixel values to RGB color space values.
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.
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.
XAllocColorCells call returned all pixel
values from zero to N - 1, where N is the colormap entries value in
visual.
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.
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] | [ ? ] |
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.
x:draw-string draws the characters of string, starting at
position.
x:image-string draws the characters and background of
string, starting at position.
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.
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.
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.
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.
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.
X:Next-Event flushes the output buffer and blocks
until an event is received.
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] | [ ? ] |
This is an alphabetical list of all the procedures and macros in Xlibscm.
| Jump to: | H X |
|---|
| Jump to: | H X |
|---|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This is an alphabetical list of all the global variables in Xlibscm.
| Jump to: | X |
|---|
| Jump to: | X |
|---|
This is an alphabetical list of concepts introduced in this manual.
| [ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |
1. Xlibscm
2. Display and Screens
3. Drawables
3.1 Windows and Pixmaps4. Graphics Context
3.2 Window Attributes
3.3 Window Properties and Visibility
5. Cursor
6. Colormap
7. Rendering
8. Images
9. Event
Procedure and Macro Index
Variable Index
Concept Index
| [Top] | [Contents] | [Index] | [ ? ] |
1. Xlibscm
2. Display and Screens
3. Drawables
4. Graphics Context
5. Cursor
6. Colormap
7. Rendering
8. Images
9. Event
Procedure and Macro Index
Variable Index
Concept Index
| [Top] | [Contents] | [Index] | [ ? ] |
| 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 | concept index | |
| [ ? ] | About | this page |
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure: