A Drawable is either a window or pixmap.
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
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!:
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.