📄 rfc1013.txt
字号:
motion-buffer-size.
Maximum-request-length specifies the maximum length of a request, in
4-byte units, accepted by the server; i.e., this is the maximum value
that can appear in the length field of a request. Requests larger
than this generate a Length error, and the server will read and
simply discard the entire request. Maximum-request-length will
always be at least 4096 (i.e., requests of length up to and including
16384 bytes will be accepted by all servers).
Per screen information:
The allowed-depths specifies what pixmap and window depths are
supported. Pixmaps are supported for each depth listed, and windows
of that depth are supported if at least one visual type is listed for
the depth. A pixmap depth of one is always supported and listed, but
windows of depth one might not be supported. A depth of zero is
never listed, but zero-depth InputOnly windows are always supported.
Root-depth and root-visual specify the depth and visual type of the
root window. Width-in-pixels and height-in-pixels specify the size
of the root window (which cannot be changed). The class of the root
window is always InputOutput. Width-in-millimeters and
height-in-millimeters can be used to determine the physical size and
the aspect ratio.
M.I.T. [Page 23]
RFC 1013 June 1987
The default-colormap is the one initially associated with the root
window. Clients with minimal color requirements creating windows of
the same depth as the root may want to allocate from this map by
default.
Black-pixel and white-pixel can be used in implementing a
"monochrome" application. These pixel values are for permanently
allocated entries in the default-colormap; the actual RGB values may
be settable on some screens.
The border of the root window is initially a pixmap filled with the
black-pixel. The initial background of the root window is a pixmap
filled with some unspecified two-color pattern using black-pixel and
white-pixel.
Min-installed-maps specifies the number of maps that can be
guaranteed to installed simultaneously (with InstallColormap),
regardless of the number of entries allocated in each map.
Max-installed-maps specifies the maximum number of maps that might
possibly be installed simultaneously, depending on their
allocations. For the typical case of a single hardware colormap,
both values will be one.
Backing-stores indicates when the server supports backing stores for
this screen, although it may be storage limited in the number of
windows it can support at once. If save-unders is True, then the a
server can support the save-under mode in CreateWindow and
ChangeWindowAttributes, although again it may be storage limited.
The current-input-events is what GetWindowAttributes would return for
the all-event-masks for the root window.
Per visual-type information:
A given visual type might be listed for more than one depth, or for
more than one screen.
For PseudoColor, a pixel value indexes a colormap to produce
independent RGB values; the RGB values can be changed dynamically.
GrayScale is treated the same as PseudoColor, except which primary
drives the screen is undefined, so the client should always store
the same value for red, green, and blue in colormaps. For
DirectColor, a pixel value is decomposed into separate RGB
subfields, and each subfield separately indexes the colormap for
the corresponding value; The RGB values can be changed dynamically.
TrueColor is treated the same as DirectColor, except the colormap
has predefined read-only RGB values, which are server-dependent,
but provide (near-)linear ramps in each primary. StaticColor is
treated the same as PseudoColor, except the colormap has
predefined read-only RGB values, which are server-dependent.
StaticGray is treated the same as StaticColor, except the red,
M.I.T. [Page 24]
RFC 1013 June 1987
green, and blue values are equal for any single pixel value,
resulting in shades of gray. StaticGray with a two-entry colormap
can be thought of as "monochrome".
The red-mask, green-mask, and blue-mask are only defined for
DirectColor and TrueColor; each has one contiguous set of bits, with
no intersections.
The bits-per-rgb-value specifies the log base 2 of the approximate
number of distinct color values (individually) of red, green, and
blue. Actual RGB values are always passed in the protocol within a
16-bit spectrum.
The colormap-entries defines the number of available colormap entries
in a newly created colormap. For DirectColor and TrueColor, this
will usually be the size of an individual pixel subfield.
SECTION 10. REQUESTS
CreateWindow
wid, parent: WINDOW
class: {InputOutput, InputOnly, CopyFromParent}
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Errors: IDChoice, Window, Pixmap, Colormap, Cursor, Match,
Value, Alloc
Creates an unmapped window, and assigns the identifier wid
to it.
A class of CopyFromParent means the class is taken from the
parent. A depth of zero for class InputOutput or
CopyFromParent means the depth is taken from the parent.
A visual of CopyFromParent means the visual type is taken
from the parent. For class InputOutput, the visual type
and depth must be a combination supported for the screen
(else a Match error); the depth need not be the same as the
parent, but the parent must not be of class InputOnly (else
a Match error). For class InputOnly, the depth must be
zero (else a Match error), and the visual must be one
supported for the screen (else a Match error), but the
parent may have any depth and class.
The server essentially acts as if InputOnly windows do not
exist for the purposes of graphics requests, exposure
M.I.T. [Page 25]
RFC 1013 June 1987
processing, and VisibilityNotify events. An InputOnly window
cannot be used as a drawable (as a source or destination for
graphics requests). InputOnly and InputOutput windows act
identically in other respects (properties, grabs, input
control, and so on).
The window is placed on top in the stacking order with
respect to siblings. The x and y coordinates are relative
to the parent's origin, and specify the position of the upper
left outer corner of the window (not the origin). The width
and height specify the inside size, not including the border,
and must be non-zero. The border-width for an InputOnly
window must be zero (else a Match error).
The value-mask and value-list specify attributes of the
window that are to be explicitly initialized. The possible
values are:
background-pixmap: PIXMAP or None or ParentRelative
background-pixel: CARD32
border-pixmap: PIXMAP or CopyFromParent
border-pixel: CARD32
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped, Always}
backing-bit-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
colormap: COLORMAP or CopyFromParent
cursor: CURSOR or None
The default values, when attributes are not explicitly
initialized, are:
background-pixmap: None
border-pixmap: CopyFromParent
bit-gravity: Forget
win-gravity: NorthWest
backing-store: NotUseful
backing-bit-planes: all ones
backing-pixel: zero
save-under: False
event-mask: {} (empty set)
do-not-propagate-mask: {} (empty set)
override-redirect: False
colormap: CopyFromParent
cursor: None
M.I.T. [Page 26]
RFC 1013 June 1987
Only the following attributes are defined for InputOnly
windows: win-gravity, event-mask, do-not-propagate-mask,
and cursor. It is a Match error to specify any other
attributes for InputOnly windows.
If background-pixmap is given, it overrides the default
background-pixel. The background pixmap and the window must
have the same root and the same depth (else a Match error).
Any size pixmap can be used, although some sizes may be
faster than others. If background None is specifed, the
window has no defined background. If background
ParentRelative is specified, the parent's background is
used, but the window must have the same depth as the parent
(else a Match error); if the parent has background None,
then the window will also have background None. A copy
of the parent's background is not made; the parent's
background is reexamined each time the window background is
required. If background-pixel is given, it overrides the
default and any background-pixmap given, and a pixmap of
undefined size filled with background-pixel is used for the
background. For a ParentRelative background, the
background tile origin always aligns with the parent's
background tile origin; otherwise the background tile
origin is always the window origin.
When regions of the window are exposed and the server has
not retained the contents, the server automatically tiles
the regions with the window's background unless the window
has a background of None, in which case the previous screen
contents are simply left in place. Exposure events are then
generated for the regions, even if the background is None.
The border tile origin is always the same as the background
tile origin. If border-pixmap is given, it overrides the
default border-pixel. The border pixmap and the window must
have the same root and the same depth (else a Match error).
Any size pixmap can be used, although some sizes may faster
than others. If CopyFromParent is given, the parent's border
pixmap is copied (subsequent changes to the parent do not
affect the child), but the window must have the same depth
as the parent (else a Match error). If border-pixel is
given, it overrides the default and any border-pixmap given,
and a pixmap of undefined size filled with border-pixel is
used for the border.
Output to a window is always clipped to the inside of the
window, so that the border is never affected.
The bit-gravity defines which region of the window should be
retained if the window is resized, and win-gravity defines
how the window should be repositioned if the parent is
M.I.T. [Page 27]
RFC 1013 June 1987
resized; see ConfigureWindow.
A backing-store of WhenMapped advises the server that
maintaining contents of obscured regions when the window
is mapped would be beneficial. A backing-store of Always
advises the server that maintaining contents even when the
window is unmapped would be beneficial. Note that, even if
the window is larger than its parent, the server should
maintain complete contents, not just the region within the
parent boundaries. If the server maintains contents,
Exposure events will not be generated, but the server may
stop maintaining contents at any time. A value of NotUseful
advises the server that maintaining contents is unnecessary,
although a server may still choose to maintain contents.
Backing-bit-planes indicates (with one bits) which bit
planes of the window hold dynamic data that must be preserved
in backing-stores. Backing-pixel specifies what value to use
in planes not covered by backing-bit-planes. The server is
free to only save the specified bit planes in the
backing-store, and regenerate the remaining planes with the
specified pixel value.
If save-under is True, the 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 window (or, for some event types, inferiors of
the window). The do-not-propagate-mask defines which events
should not be propagated to ancestor windows when no client
has the event type selected in this window.
Override-redirect specifies whether map and configure
request on this window should override a SubstructureRedirect
on the parent, typically to inform a window manager not to
tamper with the window.
The colormap specifies the colormap, that best reflects the
"true" colors of the window. Servers capable of supporting
hardware colormaps may use this information, and window
managers may use it for InstallColormap requests. The
colormap must have the same visual type as the window
(else a match error). If CopyFromParent is specified, the
parents's colormap is copied (subsequent changes to the
parent do not affect the child), but the window must have
the same visual type as the parent (else a Match error) an
the parent must not have a colormap of None (else a Match
error).
M.I.T. [Page 28]
RFC 1013 ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -