This extension provides arbitrary window and border shapes within the X11 protocol.
The restriction of rectangular windows within the X protocol can be a significant limitation. For example, many transient windows would like to display a drop shadow to give the illusion of 3 dimensions. Also, some user interface style guides call for buttons with rounded corners; the full simulation of a nonrectangular shape, particularly with respect to event distribution and cursor shape, is not possible within the Core X protocol. Finally, round clocks and nonrectangular icons are pleasant additions to the desktop.
This extension provides mechanisms for changing the visible shape of a window to an arbitrary, nonrectangular form. This extension supplements the existing semantics and does not replace them. In particular, clients that are unaware of the extension need to be able to cope with oddly-shaped windows. For example, window managers should still be able to negotiate screen real estate in rectangular pieces. Toward this end, any shape specified for a window is clipped by the bounding rectangle for the window as specified by the window's geometry in the core protocol. An expected convention would be that client programs expand their shape to fill the area offered by the window manager.
For additional information, refer to the following topics:
Each window (even with no shapes specified) is defined by two regions: the bounding region and the clip region. The bounding region is the area of the parent window which the window will occupy (including border). The clip region is the subset of the bounding region which is available for subwindows and graphics. The area between the bounding region and the clip region is defined to be the border of the window.
A nonshaped window will have a bounding region that is a rectangle spanning the window (including its border); the clip region will be a rectangle filling the inside dimensions (not including the border). In this document, these areas are referred to as the default bounding region and the default clip region. For a window with inside size of width by height and border width width, the default bounding and clip regions are the rectangles (relative to the window origin):
bounding.width = width + 2 * width
bounding.height = height + 2 * width
This extension allows a client to modify either or both of the bounding or clip regions by specifying new regions that combine with the default regions. These new regions are called the client bounding region and the client clip region. They are specified relative to the origin of the window and are always defined by offsets relative to the window origin (that is, region adjustments are not required when the window is moved). Three mechanisms for specifying regions are provided: a list of rectangles, a bitmap, and an existing bounding or clip region from a window. This is modeled on the specification of regions in graphics contexts in the Core protocol and allows a variety of different uses of the extension.
When using an existing window shape as an operand in specifying a new shape, the client region is used, unless none has been set in which case the default region is used instead.
The effective bounding region of a window is defined as the intersection of the client bounding region with the default bounding region. Any portion of the client bounding region that is not included in the default bounding region is not included in the effective bounding region on the screen. This means that window managers (or other geometry managers) accustomed to dealing with rectangular client windows can constrain the client to a rectangular area of the screen.
Construction of the effective bounding region is dynamic; the client bounding region is not mutated to obtain the effective bounding region. If a client bounding region is specified that extends beyond the current default bounding region, and the window is later enlarged, the effective bounding region will be enlarged to include more of the client bounding region.
The effective clip region of a window is defined to be the intersection of the client clip region with both the default clip region and the client bounding region. Any portion of the client clip region which is not included in both the default clip region and the client bounding region will not be included in the effective clip region on the screen.
Construction of the effective clip region is dynamic; the client clip region is not mutated to obtain the effective clip region. If a client clip region is specified, which extends beyond the current default clip region, and the window or its bounding region is later enlarged, the effective clip region will be enlarged to include more of the client clip region if it is included in the effective bounding region.
The border of a window is defined to be the difference between the effective bounding region and the effective clip region. If this region is empty, no border is displayed. If this region is not empty, the border is filled using the border tile or border pixel of the window as specified in the Core protocol. Note that a window with a nonzero border width will never be able to draw beyond the default clip region of the window. Also note that a zero border width does not prevent a window from having a border, because the clip shape can still be made smaller than the bounding shape.
All output to the window, and visible regions of any subwindows, will be clipped to the effective clip region. The server must not retain window contents beyond the effective bounding region with backing store. The window's origin (for graphics operations, background tiling, and subwindow placement) is not affected by the existence of a bounding region or clip region.
Areas that are inside the default bounding region but outside the effective bounding region are not part of the window; these areas of the screen will be occupied by other windows. Input events that occur within the default bounding region but outside the effective bounding region will be delivered as if the window was not occluding the event position. Events which occur in a nonrectangular border of a window will be delivered to that window, just as for events which occur in a normal rectangular border.
An InputOnly window can have its bounding region set, but it is a Match error to attempt to set a clip region on an InputOnly window or to specify its clip region as a source to a request in this extension.
The server must accept changes to the clip region of a root window, but the server is permitted to ignore requested changes to the bounding region of a root window. If the server accepts bounding region changes, the contents of the screen outside the bounding region are implementation-dependent.
The following types are used in the request and event definitions in subsequent sections:
SHAPE_KIND:
{Bounding,
Clip}
SHAPE_OP:
{Set,
Union,
Intersect,
Subtract,
Invert}
The C Language routines provide direct access to the protocol and add no additional semantics.
All XShape Extension functions and procedures, and all manifest constants and macros, start with the string "XShape". All routines that have return type Status will return non-zero for success and zero for failure. Even if the XShape Extension is supported, the server may withdraw such facilities arbitrarily; in which case they will subsequently return zero.
The XShape Extension includes the following C Language routines: