", Hyphenation = on, Consecutive Hyphens = 2, Vert. Just. = off> ", Level 1 Show = no, Level 2 Suffix = , Level 2 Starting Value = 0, Level 2 Show = no> ", Level 1 Show = no, Level 2 Suffix = "<#04>"> ", Level 1 Show = no, Level 2 Suffix = > ", Level 1 Show = no, Level 2 Suffix = "<#04>"> Introduction to CLX ) (E10,0,0,0,1,0,0.053333,1,15,0,0,1,0,0,0,0,1,0,1,0.066667,0.066667,6,6,0,0.066 667,6))> Introduction to CLX ) (E10,0,0,0,1,1,0.053333,1,15,0,0,1,0,0,0,0,1,1,1,0.066667,0.066667,6,6,0,0.066 667,6))> <|,"1<#1e>1"> INTRODUCTION TO CLX ) (E10,0,0,0,1,0,0.053333,1,15,0,0,1,0,0,0,0,1,0,1,0.066667,0.066667,6,6,0,0.066 667,6))> ) (T8,2,12,0.026667,0.733333,0,1,0.333333,0,516,0,17,0,0,0,0,0,0,1,1,2048,512,10 2,1101,3, <"table"> ) (T8,3,12,0.066667,0.6,0,1,0.333333,0,516,0,17,0,0,0,0,0,0,1,1,2048,512,102,110 1,3, ) (g9,5,0 (p7,5,8,19 (g9,5,0 (g9,5,0 (v4,5,0,0.266667,0,1.6,0,17,1,0) (v4,6,0,1.6,0,1.6,0.933333,17,1,0) (v4,7,0,1.6,0.933333,0.266667,0.933333,17,1,0) (v4,8,0,0.266667,0.933333,0.266667,0,17,1,0)))) (g9,10,8 (p7,10,0,13 (g9,10,0 (g9,10,0 (v4,10,0,1.471112,0.927404,1.471112,0.159997,17,1,0) (v4,11,0,1.471112,0.159997,1.293333,0.159997,17,1,0) (v4,12,0,1.293333,0.159997,1.115556,0.306168,17,1,0) (v4,13,0,1.115556,0.306168,1.115556,0.379256,17,1,0) (v4,14,0,1.115556,0.379256,1.271111,0.379256,17,1,0) (v4,15,0,1.271111,0.379256,1.271111,0.927404,17,1,0) (v4,16,0,1.271111,0.927404,1.471112,0.927404,17,1,0)))) (g9,17,2048 (v4,17,33,1.093333,0.159997,1.093333,0.159997,17,0,0) (v4,18,33,1.093333,1.146663,1.093333,1.146663,17,0,0) (v4,19,33,1.56,1.146663,1.56,1.146663,17,0,0) (v4,20,33,1.56,0.159997,1.56,0.159997,17,0,0)))) (E10,0,0,0,1,1,0.053333,1,15,0,0,1,0,0,0,0,1,1,1,0.066667,0.066667,6,6,0,0.066 667,6))> Introduction1.1<#04>This manual assumes a basic understanding of window systems and the Common Lisp programming language. To provide an introduction to the Common Lisp X Interface (CLX) programming, this section discusses the following:<#04> wOverview of the X Window System wNaming and argument conventions wProgramming considerations The X Window1.2<#04>The X Window System was developed at the Massachusetts Institute of SystemTechnology (MIT) and first released in 1985. Since then, the X Window System has become an industry<#1e>standard product available on virtually every type of bit<#1e>mapped workstation. The current version of X, Version 11, has been implemented for several different computer architectures, for a wide variety of display hardware, and also for many different operating systems. X Version 11 represents the fulfillment of the original design goals proposed by MIT, as follows:<#04> wPortable <#1f> Support virtually any bitmap display and any interactive input device (including keyboards, mice, tablets, joysticks, and touch screens). Make it easy to implement the window system on different operating systems. wDevice<#1e>Independent Applications <#1f> Avoid rewriting, recompiling, or even relinking in order to use different display/input hardware. Make it easy for an application to work on both monochrome and color hardware. wNetwork Transparent <#1f> Let an application run on one computer while using another computer's display, even if the other computer has a different operating system or hardware architecture. wMultitasking <#1f> Support multiple applications being displayed simultaneously. wNo User Interface Policy <#1f> Since no one agrees on what constitutes the best user interface, make it possible for a broad range of user interface styles (or policies) to be implemented, external to the window system and to the application programs. wCheap Windows <#1f> Windows should be abundant, and ubiquitous. Provide overlapping windows and a simple mechanism for window hierarchy. wHigh<#1e>Performance Graphics <#1f> Provide powerful interfaces for synthesizing 2<#1e>D images (geometric primitives, high<#1e>quality text with multiple typefaces, and scanned images). wExtensible <#1f> Include a mechanism for adding new capabilities. Allow separate sites to develop independent extensions without becoming incompatible with remote applications. <|,"1<#1e>2">Some of these goals lead directly to the basic X architecture <#1f> the client<#1e>server model. The basic window system is implemented by the X server program. An application program (the client) sends window system requests to the X server through a reliable two<#1e>way byte<#1e>stream. In general, the server and the client can be executing on separate host computers, in which case the byte<#1e>stream is implemented via some network protocol (TCP, DECnet], Chaosnet, and so forth). The X server, which is connected to several client programs running concurrently, executes client requests in round<#1e>robin fashion. The server is responsible for drawing client graphics on the display screen and for making sure that graphics output to a window stays inside its boundary. The other primary job of the X server is to channel input from the keyboard, pointer, and other input devices back to the appropriate client programs. Input arrives at the client asynchronously in the form of input events representing up/down transitions of keys or pointer buttons, changes in the pointer position, and so on. In some cases, a request generates a return value (or reply) from the server, which is another kind of client input. Replies and input events are received via the same byte<#1e>stream connecting the client with the server. Windows1.2.1<#04>The X Window System supports one or more screens containing overlapping windows and subwindows. A screen is a physical monitor and hardware, which can be either color or black and white. There can be multiple screens per display workstation. A single server can provide display services for any number of screens. A set of screens for a single user with one keyboard and one mouse is called a display. All windows in an X server are arranged in a strict hierarchy. At the top of the hierarchy are the root windows, which cover each of the display screens. Each root window is either partially or completely covered by child windows. All windows, except for root windows, have parents. Any window can in turn have its own children. In this way, an application program can create a window tree of arbitrary depth on each screen. A child window can be larger than its parent. That is, part or all of the child window can extend beyond the boundaries of the parent. However, all output to a window is clipped by the boundaries of its parent window. If several children of a window have overlapping locations, one of the children is considered to be on top of/or raised over the others, obscuring them. Window output to areas that are covered by other windows is suppressed. A window has a border that is zero or more pixels in width and can be any pattern (pixmap) or solid color. A window usually has a background pattern that is drawn by the X server. Each window has its own coordinate system. Child windows obscure their parents unless the child windows have no background. Graphics operations in the parent window are usually clipped by the children. X also provides objects called pixmaps for off<#1e>screen storage of graphics. Single<#1e>plane pixmaps (that is, of depth 1) are sometimes referred to as bitmaps. Both pixmaps and windows can be used interchangeably in most graphics functions. Pixmaps are also used in various graphics operations to define patterns, or tiles . Windows and pixmaps together are referred to as drawables. Input Events1.2.2<#04>The X input mechanism is conceptually simple yet quite powerful. Most events are attached to a particular window (that is, contain an identifier for the window receiving the event). A client program can receive multiple window input streams, all multiplexed over the single byte<#1e>stream connection to the server. <|,"1<#1e>3">Clients can tailor their input by expressing interest in only certain event types. The server uses special event types to send important messages to the client. For example, the client can elect to receive an :enter<#1e>notify event when the pointer cursor moves into a certain window. Another vital message from the server is an :exposu re event. This is a signal to the client indicating that at least some portion of the window has suddenly become visible (perhaps the user moved another window which had been overlapping it). The client is then responsible for doing what is necessary to redisplay the window's image. Client programs must be prepared to regenerate the contents of windows in this way on demand. Input is also subject to policy decisions about which client window receives keyboard and pointer events. Since the pointer is free to roam between windows, just clicking on a window is often enough to send a pointer event to that window. Keyboard events, however, must go to a keyboard focus window which has to be designated in some other way. Usually, the arbiter of such input management policy is a program called the window manager. The window manager gives the human user a way to make a window the keyboard focus, to manage the layout of windows on the screen, to represent windows with icons, and so forth. In fact, the window manager client determines most of the so<#1e>called look and feel of the X Window System. A Quick Tour1.3<#04>The X Window System is defined by the X Window System Protocol of CLXSpecification, a detailed description of the encoding and the meaning of requests and events sent between a client and a server. This standard protocol does not depend on any particular programming language. As a result, each programming language must define its own functional interface for using the X protocol. The standard X interface used by Common Lisp programmers is called CLX. CLX is a set of data types, functions, and macros which allow a Common Lisp client program to interact with an X server to send requests and to receive input events and replies.<#04> For the most part, CLX functions are closely tied to the underlying requests in the X protocol. Many CLX functions simply add requests to an output buffer. These requests later execute asynchronously on the X display server. However, some functions of CLX lie outside the scope of the protocol<#1f>for example, reading events and managing a client<#1e>side event queue. CLX is also responsible for important batching and caching tasks that minimize network communication. The following paragraphs show an example of a CLX client program. All CLX functions and macros are shown in upper case. Note that some of the terms used are unique to X, while other terms that are common to other window systems have different meanings in X. It may be helpful to refer to the glossary when you are uncertain of a term's meaning in the context of the X Window System. A Simple Menu1.3.1<#04>The example client program creates and displays a simple pop<#1e>up menu consisting of a column of strings<#1f>a title string followed by selectable menu item strings. The implementation uses one window to represent the entire menu, plus a set of subwindows, one for each menu item. Here is the definition of a structure which represents such a menu. <|,"1<#1e>4">(defstruct (menu)
<#7f>A simple menu of text strings."
(title <#7f>Choose an item:")
item-alist ;((item-window item-string))
window
gcontext
width
title-width
item-width
item-height
(geometry-changed-p t)) ;nil if unchanged since displayed The window slot will contain the window object that represents the menu. The item<#1e>alist represents the relationship between the menu items and their associated subwindows. Each entry in item<#1e>alist is a list whose first element is a (sub)window object and whose second element is the corresponding item string. A window object is an instance of a CLX<#1e>defined data type which represents X windows. A window object actually carries two pieces of information: an X window ID integer and a display object. A display is another CLX<#1e>defined data type that represents a connection to a specific X display server. The gcontext slot contains an instance of a CLX data type known as a graphics context. A graphics context is a set of display attribute values, such as foreground color, fill style, line style, text font, and so forth. Each X graphics request (and hence each CLX graphics function call) must supply a graphics context to use in displaying the request. The menu's gcontext will thus hold all of the attribute values used during menu display. <|,"1<#1e>5">The first thing to do is make an instance of a menu object: (defun create-menu (parent-window text-color background-color
<#04>text-font)
(make-menu
;; Create menu graphics context
gcontext", Sort String = "create<#1e>gcontext", "example">:gcontext (CREATE-GCONTEXT :drawable parent-window
:foreground text-color
:background background-color
:font text-font)
;; Create menu window
window", Sort String = "create<#1e>window", "example">:window (CREATE-WINDOW
:parent parent-window
:class :input-output
:x 0 ;temporary value
:y 0 ;temporary value
:width 16 ;temporary value
:height 16 ;temporary value
:border-width 2
:border text-color
:background background-color
:save-under :on
:override-redirect :on ;override window mgr when positioning
event<#1e>mask", Sort String = "make<#1e>event<#1e>mask", "example">:event-mask (MAKE-EVENT-MASK :leave-window
:exposure)))) create<#1e>window is one of the most important CLX functions, since it creates and returns a window object. Several of its options are shown here. The default window class is :input<#1e>output , but X provides for :input<#1e>only windows, too. Every window must have a parent window, except for a system<#1e>defined ro ot window, which represents an entire display screen. The :event<#1e> mask keyword value, a CLX event<#1e>mask data type, says that an input event will be received for the menu window when the window is exposed and also when the pointer cursor leaves the window. The window border is a pattern<#1e>filled or (as in this case) a solid<#1e>colored boundary which is maintained automatically by the X server; a client cannot draw in a window's border, since all graphics requests are relative to the origin (upper<#1e>left corner) of the window's interior and are clipped by the server to this inside region. Turning on the :save<#1e>under option is a hint to the X server that, when this window is made visible, it may be more efficient to save the pixels it obscures, rather than require several client programs to refresh their windows when the pop<#1e>up menu disappears. This is a way to work around X's client<#1e>managed refresh policy when only a small amount of screen space is needed temporarily. Why is :override<#1e>redirect turned on for the menu window? This is actually a little unusual, because it prevents any window manager client from redirecting the position of the menu when it is popped up. Remember that the window manager represents the user's policy for controlling the positions of his windows, so this kind of redirection is ordinarily correct. However, in this case, as a favor to the user, the menu avoids redirection in order to pop up the menu at a very specific location; that is, under the pointer cursor. What about the item subwindows? The menu<#1e>set<#1e>i tem<#1e>list function in the following example creates them whenever the menu's item list is changed. The upper<#1e>left x and y coordinates and the width and height are not important yet, because they are computed just before the menu is displayed. This function also calls create<#1e>win dow, demonstrating the equal treatment of parent and children windows in the X window hierarchy. <|,"1<#1e>6">(defun menu-set-item-list (menu &rest item-strings)
;; Assume the new items will change the menu's width and height
(setf (menu-geometry-changed-p menu) t)
;; Destroy any existing item windows
(dolist (item (menu-item-alist menu))
window", Sort String = "destroy<#1e>window", "example"> (DESTROY-WINDOW (first item)))
;; Add (item-window item-string) elements to item-alist
(setf (menu-item-alist menu)
(let (alist)
(dolist (item item-strings (nreverse alist))
window", Sort String = "create<#1e>window", "example"> (push (list (CREATE-WINDOW
:parent (menu-window menu)
:x 0 ;temporary value
:y 0 ;temporary value
:width 16 ;temporary value
:height 16 ;temporary value
background", Sort String = "gcontext<#1e>background", "example"> :background (GCONTEXT-BACKGROUND (menu-gcontext menu))
event<#1e>mask", Sort String = "make<#1e>event<#1e>mask", "example"> :event-mask (MAKE-EVENT-MASK :enter-window
:leave-window
:button-press
:button-release))
item)
alist))))) Displaying1.3.2<#04>The menu<#1e>r ecompute<#1e>geometry function (shown in the following the Menuexample) handles the job of calculating the size of the menu, based on its current item list and its current text font. CLX provides a way to inquire the geometrical properties of a font object (for example, its ascent and descent from the baseline) and also a text<#1e>extents function. text<#1e>extents returns the geometry of a given string as displayed in a given font. Notice the use of the with<#1e>state macro when setting a window's geometry attributes. CLX strives to preserve the familiar setf style of accessing individual window attributes, even though an attribute access actually involves sending a request to a (possibly remote) server and/or waiting for a reply. with<#1e>state tells CLX to batch together all read and write accesses to a given window, using a local cache to minimize the number of server requests. This CLX feature can result in a dramatic improvement in client performance without burdening the programmer interface.<#04> menu<#1e>recompute<#1e>geometry causes all the item subwindows to become mapped. Mapping a window means attempting to make it visible on the screen. However, a subwindow will not actually be visibl e until it and all of its ancestors are mapped. Even then, another window might be covering up the subwindow. <|,"1<#1e>7">font", Sort String = "gcontext<#1e>font", "example">extents", Sort String = "text<#1e>extents", "example">ascent", Sort String = "font<#1e>ascent", "example">descent", Sort String = "font<#1e>descent", "example">state", Sort String = "with<#1e>state", "example">width", Sort String = "drawable<#1e>width", "example">height", Sort String = "drawable<#1e>height", "example">x", Sort String = "drawable<#1e>x", "example">y", Sort String = "drawable<#1e>y", "example">subwindows", Sort String = "map<#1e>subwindows", "example"> (defun menu-recompute-geometry (menu)
(when (menu-geometry-changed-p menu)
(let* ((menu-font (GCONTEXT-FONT (menu-gcontext menu)))
(title-width (TEXT-EXTENTS menu-font (menu-title menu)))
(item-height (+ (FONT-ASCENT menu-font)
(FONT-DESCENT menu-font)
*menu-item-margin*))
(item-width 0)
(items (menu-item-alist menu))
menu-width)
;; Find max item string width
(setf item-width
(+ *menu-item-margin*
(dolist (next-item items item-width)
(setf item-width (max item-width
(TEXT-EXTENTS menu-font (second next-item)))))))
;; Compute final menu width, taking margins into account
(setf menu-width (max title-width (+ item-width *menu-item-margin*)))
(let ((window (menu-window menu)))
;; Update width and height of menu window
(WITH-STATE (window)
(setf (DRAWABLE-WIDTH window) menu-width
(DRAWABLE-HEIGHT window) (* (1+ (length items)) item-height)))
;; Update width, height, position of item windows
(let ((item-left (round (- menu-width item-width) 2))
(next-item-top (- item-height (round *menu-item-margin* 2))))
(dolist (next-item items)
(let ((window (first next-item)))
(WITH-STATE (window)
(setf (DRAWABLE-HEIGHT window) item-height
(DRAWABLE-WIDTH window) item-width
(DRAWABLE-X window) item-left
(DRAWABLE-Y window) next-item-top)))
(incf next-item-top item-height))))
;; Map all item windows
(MAP-SUBWINDOWS (menu-window menu))
;; Save item geometry
(setf (menu-item-width menu) item-width
(menu-item-height menu) item-height
(menu-width menu) menu-width
(menu-title-width menu) title-width
(menu-geometry-changed-p menu) nil)))) Of course, the sample client must know how to draw/redraw the menu and its items, so the function menu<#1e>refresh is defined next to handle that task (shown in the following example). Note that the location of window output is given relative to the window origin. Windows and subwindows have different coordinate systems. The location of the origin (upper<#1e>left corner) of a subwindow's coordinate system is given with respect to its parent window's coordinate system. Negative coordinates are valid, although only output to the +x/+y quadrant of a window's coordinate system will ever be visible. <|,"1<#1e>8">ascent", Sort String = "font<#1e>ascent", "example">font", Sort String = "gcontext<#1e>font", "example">background", Sort String = "gcontext<#1e>background", "example">foreground", Sort String = "gcontext<#1e>foreground", "example">gcontext", Sort String = "with<#1e>gcontext", "example">image<#1e>glyphs", Sort String = "draw<#1e>image<#1e>glyphs", "example"> (defun menu-refresh (menu)
(let* ((gcontext (menu-gcontext menu))
(baseline-y (FONT-ASCENT (GCONTEXT-FONT gcontext))))
;; Show title centered in <#7f>reverse-video"
(let ((fg (GCONTEXT-BACKGROUND gcontext))
(bg (GCONTEXT-FOREGROUND gcontext)))
(WITH-GCONTEXT (gcontext :foreground fg :background bg)
(DRAW-IMAGE-GLYPHS
(menu-window menu)
gcontext
(round (- (menu-width menu)
(menu-title-width menu)) 2) ;start x
baseline-y ;start y
(menu-title menu))))
;; Show each menu item (position is relative to item window)
(let ((box-margin (round *menu-item-margin* 2)))
(dolist (item (menu-item-alist menu))
(DRAW-IMAGE-GLYPHS
(first item) gcontext
box-margin ;start x
(+ baseline-y box-margin) ;start y
(second item)))))) with<#1e>gcontext is a CLX macro that allows you temporarily to modify a graphics context within the dynamic scope of the macro body. draw<#1e>image<#1e>glyphs is a CLX text drawing function which produces a terminal<#1e>like rendering: foreground character on a background block. (More sophisticated text rendering functions are also available.) The strange use of glyphs instead of string here actually highlights an important fact: X and Common Lisp have totally different concepts of a character. A Common Lisp character is an object whose implementation can comprehend a vast universe of text complexities (typefaces, type styles, international character sets, symbols, and so forth). However, to X, a string is just a sequence of integer indexes into the array of bitmaps represented by a CLX font object. In general, draw<#1e>image<#1e>glyphs, text<#1e>ext ents, and other CLX text functions accept a :translate keyword argument. Its value is a function which translates the characters of a string argument into the appropriate font<#1e>and<#1e>index pairs needed by CLX. This example relies upon the default translation function, which simply uses char<#1e>code to compute an index into the current font. Menu Input1.3.3<#04>Now that a menu can be displayed, the sample client program must define how the menu will process user input. The menu<#1e>choose function (shown in the following example) has the classic structure of an X client program. First, do some initialization (for example, present the menu at a given location). Then, enter an input event loop. Read an input event, process it, and repeat the loop until a termination event is received. The event<#1e>case macro continues reading an event from the menu window's display object until one of its clauses returns non<#1e>nil. These clauses specify the action to be taken for each event type and also bind values from the event report to local variables, such as the event<#1e>window receiving the event. Notice that the :force<#1e>output<#1e>p option is enabled, causing event<#1e>case to begin by sending any client requests which CLX has not yet output to the server. To improve performance, CLX quietly queues up requests and periodically sends them off in a batch. However, in an interactive feedback loop such as this, it is important to keep the display crisply up<#1e>to<#1e>date. <|,"1<#1e>9">case", Sort String = "event<#1e>case", "example">display", Sort String = "drawable<#1e>display", "example">release event", Sort String = "button<#1e>release event", "example">release", Sort String = "button<#1e>release", "example">notify event", Sort String = "enter<#1e>notify event", "example">notify", Sort String = "enter<#1e>notify", "example">notify event", Sort String = "leave<#1e>notify event", "example">notify", Sort String = "leave<#1e>notify", "example">window", Sort String = "unmap<#1e>window", "example"> (defun menu-choose (menu x y)
;; Display the menu so that first item is at x,y.
(menu-present menu x y)
(let ((items (menu-item-alist menu))
(mw (menu-window menu))
selected-item)
;; Event processing loop
(do () (selected-item)
(EVENT-CASE ((DRAWABLE-DISPLAY mw) :force-output-p t)
(:exposure
(count)
;; Discard all but final :exposure then display the menu
(when (zerop count) (menu-refresh menu))
t)
(:button-release
(event-window)
;;Select an item
(setf selected-item (second (assoc event-window items)))
t)
(:enter-notify
(window)
;;Highlight an item
(menu-highlight-item menu (find window items :key #'first))
t)
(:leave-notify
(window kind)
(if (eql mw window)
;; Quit if pointer moved out of main menu window
(setf selected-item (when (eq kind :ancestor) :none))
;; Otherwise, unhighlight the item window left
(menu-unhighlight-item menu (find window items :key #'first)))
t)
(otherwise
()
;;Ignore and discard any other event
t)))
;; Erase the menu
(UNMAP-WINDOW mw)
;; Return selected item string, if any
(unless (eq selected-item :none) selected-item))) The event loop in menu<#1e>choose demonstrates an idiom used in all X programs: the contents of a window are displayed (in this case, by calling menu<#1e>refresh) only when an :exposure event is received, signaling that the server has actually made the window viewable. The handling of :exposure in menu<#1e>choose also implements a little trick for improving efficiency. In general, when a window is exposed after being previously obscured (perhaps only partially), the server is free to send several :exp osure events, one for each rectangular tile of the exposed region. For small windows like this menu, it is not worth the trouble to redraw the image one tile at a time. So the code above just ignores all but the last tile exposure and redraws everything in one call to menu<#1e>refr esh. <|,"1<#1e>10"> The Main1.3.4<#04>After all the preceding build<#1e>up and the other functions referenced Program(but not shown here) have been implemented, the code for the main client program is very small. display", Sort String = "open<#1e>display", "example">roots", Sort String = "display<#1e>roots", "example">black<#1e>pixel", Sort String = "screen<#1e>black<#1e>pixel", "example">white<#1e>pixel", Sort String = "screen<#1e>white<#1e>pixel", "example">font", Sort String = "open<#1e>font", "example">root", Sort String = "screen<#1e>root", "example">pointer", Sort String = "query<#1e>pointer", "example">display", Sort String = "close<#1e>display", "example"> (defun just-say-lisp (host &optional (font-name <#7f>fg-16"))
(let* ((display (OPEN-DISPLAY host))
(screen (first (DISPLAY-ROOTS display)))
(fg-color (SCREEN-BLACK-PIXEL screen))
(bg-color (SCREEN-WHITE-PIXEL screen))
(nice-font (OPEN-FONT display font-name))
;; Create a menu as a child of the root window.
(a-menu (create-menu (SCREEN-ROOT screen)
fg-color bg-color nice-font)))
(setf (menu-title a-menu) <#7f>Please pick your favorite language:")
(menu-set-item-list a-menu <#7f>Fortran" <#7f>APL" <#7f>Forth" <#7f>Lisp")
;; Bedevil the user until he picks a nice programming language
(unwind-protect
(loop
;; Determine the current root window position of the pointer
(multiple-value-bind (x y) (QUERY-POINTER (SCREEN-ROOT screen))
(let ((choice (menu-choose a-menu x y)))
(when (string-equal <#7f>Lisp" choice)
(return)))))
(CLOSE-DISPLAY display)))) Note that the main program event loop lies in the body of an unwind<#1e>pr otect form. This is a good programming technique because, without this protection, an unexpected error could cause the program to terminate without freeing the server resources it has created. Server resources are CLX objects which refer to objects actually stored on the X server. Examples of these are window, font, pixmap, cursor, colormap, and gcontext objec ts. These server resources are created and destroyed by user requests. Server resources created by a client are also destroyed when its display connection is closed. If client resources are repeatedly created without being destroyed, then the server will eventually run out of memory and fail. Most server resources are potentially sharable between applications. In fact, windows are manipulated explicitly by window manager programs. Fonts and cursors are typically shared automatically since the X server loads and unloads font storage as needed. gcontext objects are not ordinarily shared between client applications. Debugging1.3.5<#04>Typically, most CLX programs do not need to control the buffering With CLXof output requests directly. However, CLX programmers need to be aware of the asynchronous nature of client<#1e>serve r communication. It may be convenient to control the CLX output buffer more directly, especially during debugging. A client that wants a request to execute immediately instead of asynchronously can follow it with a call to display<#1e>force<#1e>output. This function blocks (does not return) until all previously buffered output requests have been sent. Otherwise, the output buffer is always flushed by a call to any function which returns a value from the server or which waits for input (for example, get<#1e>property ). Certain output requests can cause input events to be sent. For example, map<#1e>window can cause :exposure events to be sent. Synchronizing output with the resulting input can be done with the display<#1e>finish<#1e>output function. This function blocks until all previously buffered output has been sent and all resulting input events have been received. <|,"1<#1e>11">Functions that return information from the server block until an explicit reply is received or an error occurs. If a nonblocking call results in an error, the error is generally not reported until later. All errors (synchronous and asynchronous) are processed by calling an error handler defined for the display. If the handler is a sequence it is expected to contain handler functions specific to each error. The error code is used to index the sequence, fetching the appropriate handler. Any results returned by the handler are ignored since it is assumed that the handler either takes care of the error completely, or else signals. Naming and1.4<#04>Throughout CLX, a number of conventions for naming and syntax of Argumentthe CLX functions have been followed. These conventions are intended to Conventionsmake the syntax of the functions more predictable. <#04> The major naming conventions are as follows: wTo better differentiate the CLX symbols from other symbols, they have all been placed in the package XLIB. External symbols have been explicitly exported. wThe display argument, where used, is always first in the argument list. wAll server resource objects, where used, occur at the beginning of the argument list, immediately after the display variable. wWhen a graphics context (gcontext) is present together with another type of server resource (most commonly, a drawable ), the graphics context occurs in the argument list after the other server resource. Drawables out rank all other server resources. wSource arguments always precede the destination arguments in the argument list. wThe x argument always precedes the y argument in the argument list. wThe width argument always precedes the height argument in the argument list. wWhere the x, y, width and height arguments are used together, the x and y arguments always precede the width and height arguments. wWhere a mask is accompanied with a structure , the mask always precedes the structure in the argument list. Programming1.5<#04>The major programming considerations are as follows: <#04> Considerations wKeyboards are the greatest variable between different manufacturer's workstations. If you want your program to be portable, you should be particularly conservative here. wMany display systems have limited amounts of off<#1e>screen memory. If you can, you should minimize use of pixmaps and backing store. wThe user should have control of his screen real<#1e>estate. Therefore, you should write your applications to react to window management, rather than presume control of the entire screen. What you do inside of your top level window, however, is up to your application. <|,"1<#1e>12">wCoordinates and sizes in X are actually 16<#1e>bit quantities. They usually are declared as an int16 in the functions. Values larger than 16 bits can be truncated silently. Sizes (width and height) are unsigned quantities. wThe types color, colormap, cursor , display, font, gcontext, pixmap, screen, and window are defined solely by a functional interface. Even though they are treated like structures in this document, it is not specified whether they are implemented as structures or classes. Although some interfaces are described as functions, they are not required to be defined using defun. (It is a requirement that they be functions as opposed to macros or special forms.) Data Types1.6<#04>The following are some data type definitions that are commonly used in CLX function definitions. alist (key<#1e>type<#1e>and<#1e>name datum<#1e>type<#1e>and<#1e>name ) 'listType alist defines an association list. An association list is a sequence, containing zero or more repetitions of the given elements with each of the elements expressed as (type name). angle `(number ,(* -2pi) ,(* 2pi))Type angle defines an angle in units of radians and is bounded by (-2p) and (2p). Note that we are explicitly using a different angle representation than what is actually transmitted in the protocol. arc<#1e>seq '(repeat<#1e>seq (int16 x) (int16 y) (card16 width) (card16 height) Typeseq", Sort String = "arc<#1e>seq">
(angle angle1) (angle angle2)) arc<#1e>seq defines a six<#1e>tuple sequence of the form (x, y, width, height, angle1, angle2). The points x and y are signed, 16<#1e>bit quantities with a range from -32,768 to 32,767. The width and height values are unsigned, 16<#1e>bit quantities and range from 0 to 65,535. angle1 and angle2 are in units of radians, and bounded by (-2p) and (2p). array<#1e>index `(integer 0 ,array<#1e>dimension<#1e>limit )Typeindex", Sort String = "array<#1e>index"> array<#1e>index defines a type which is a subtype of the integers and can be used to describe all variables that can be array indices. The range is inclusive because start and end array index specifiers can be one (1) past the end. bit<#1e>gravity '(member gravity*)Typegravity", Sort String = "bit<#1e>gravity"> A keyword that specifies which region of a window should be retained when the window is resized. gravity <#1f> One of the following: :center:north:south:static
:east:north<#1e>east:south<#1e>east:west
:forget:north<#1e>west:south<#1e>west If a window is reconfigured without changing its inside width or height, then the contents of the window moves with the window and are not lost. Otherwise, the contents of a resized window are either moved or lost, depending on its bit<#1e>gravity attribute. See window<#1e>bit<#1e> gravity, in paragraph 4.3, Window Attributes, for additional information. bitmap '(array bit (* *))Type Specifies a two<#1e>dimensional array of bits. <|,"1<#1e>13"> bitmap<#1e>formatStructureformat", Sort String = "bitmap<#1e>format"> A structure that describes the storage format of a bitmap. The bitmap<#1e>format structure contains slots for unit, pad, and lsb<#1e>first<#1e>p. The unit member indicates the unit of increments used to maintain the bitmap data. The units available for use are 8, 16, or 32 bits. The pad member indicates how many bits are needed to pad the left edge of the scan<#1e>line. The lsb<#1e>first<#1e>p member is a predicate which indicates the ordering of bits with the bitmap unit. unitSlot of bitmap<#1e>format Type: (member 8 16 32). The size of a contiguous grouping of bits, which can be 8, 16, or 32. The default is 8. padSlot of bitmap<#1e>format Type: (member 8 16 32). The number of bits to left<#1e>pad the scan<#1e>line, which can be 8, 16, or 32. The default is 8. lsb<#1e>first<#1e>pSlot of bitmap<#1e>format Type: boolean. A predicate indicating whether the least significant bit comes first (true) or not (nil). <|,"1<#1e>14">boolean '(or nil (not nil)) Type boolean defines a type which is all inclusive. It is used for variables that can take on a true (non<#1e>nil) or false (nil) value. boole<#1e>constant `(member value*) Typeconstant", Sort String = "boole<#1e>constant"> boole-constant defines a type that is a set of the values associated with the 16 boolean operation<#1e>code constants for the Common Lisp language. It is used for the set of allowed source and destination combination functions in a graphics context. value <#1f> One of the following: boole<#1e>1boole<#1e>c1boole<#1e>nandboole<#1e>xor
boole<#1e>2boole<#1e>c2boole<#1e>nor
boole<#1e>andboole<#1e>clrboole<#1e>orc1
boole<#1e>andc1boole<#1e>eqvboole<#1e>orc2
boole<#1e>andc2boole<#1e>iorboole<#1e>set card8 '(unsigned<#1e>byte 8)Type An unsigned integer value that is a maximum of eight bits long. This gives a number of this type a range from 0 to 255. card16 '(unsigned<#1e>byte 16)Type An unsigned integer value that is a maximum of 16 bits long. This gives a number of this type a range from 0 to 65,535. card29 '(unsigned<#1e>byte 29)Type An unsigned integer value that is a maximum of 29 bits long. This gives a number of this type a range from 0 to 536,870,911. card32 '(unsigned<#1e>byte 32)Type An unsigned integer value that is a maximum of 32 bits long. This gives a number of this type a range from 0 to 4,294,967,295. color '(satisfies color<#1e>p)Type A color. See paragraph 9.2, Color Functions, for additional information. colormap '(satisfies colormap<#1e>p)Typ e A colormap. See paragraph 9.3, Colormap Functions, for additional information. cursor '(satisfies cursor<#1e>p)Type A cursor. See Section 10, Cursors, for additional information. device<#1e>event<#1e>mask '(or mask32 (list device<#1e>even t<#1e>mask<#1e>class))Typeevent<#1e>mask", Sort String = "device<#1e>event<#1e>mask"> Provides a way to specify a set of bits for an event bitmask. Two ways of specifying the bits are allowed: by setting the event bits in a 32 bit mask, or by listing the keyword names of the device related event bits in a list. device<#1e>event<#1e>mask<#1e>class '(member event*) Typeevent<#1e>mask<#1e>class", Sort String = "device<#1e>event<#1e>mask<#1e>class"> A keyword name, for a device related event, that corresponds to a particular bit in an event bitmask. The set of names is a subset of the names in the type event<#1e>mask<#1e>class. event <#1f> One of the following: <|,"1<#1e>15">:button<#1e>1<#1e>motion:button<#1e>motion
:button<#1e>2<#1e>motion:button<#1e>press
:button<#1e>3<#1e>motion:key<#1e>press
:button<#1e>4<#1e>motion:key<#1e>release
:button<#1e>5<#1e>motion:pointer<#1e>motion display '(satisfies display<#1e>p)Type A connection to an X server. See Section 2, Displays, for additional information. drawable '(or window pixmap)Type Both windows and pixmaps can be used as sources and destinations in graphics operations. windows and pixmaps together are known as drawables. However, an :input<#1e>on ly window cannot be used as a source or destination in a graphics operation. draw<#1e>direction '(member :left<#1e>to<#1e>right :right<#1e>to<#1e>left)Typedirection", Sort String = "draw<#1e>direction"> Defines a list of rotation directions for drawing arcs and fonts. draw<#1e> direction can have the values of :left<#1e>to<#1e>right or :right<#1e>to<#1e>left. error<#1e>key '(member error*)Typekey", Sort String = "error<#1e>key"> Defines a list of all predefined errors. All errors (synchronous and asynchronous) are processed by calling an error handler in the display. The handler is called with the display as the first argument and the error<#1e>key as its second argument. error <#1f> One of the following: :access:drawable:implementation:value
:alloc:font:length:window
:atom:gcontext:match
:colormap:id<#1e>choice:name
:cursor:illegal<#1e>request:pixmap event<#1e>key '(member event<#1e>type*) Typekey", Sort String = "event<#1e>key"> Defines a list that specifies all predefined event<#1e>types. Clients are informed of information asynchronously by means of events. These events can be either asynchronously generated from devices or generated as side effects of client requests. event<#1e>type <#1f> One of the following: :button<#1e>press:exposure:motion<#1e>notify
:button<#1e>release:focus<#1e>in :no<#1e>exp osure
:circulate<#1e>notify:focus<#1e>out:property <#1e>notify
:circulate<#1e>request:graphics<#1e>exposure :reparent<#1e>notify
:client<#1e>message:gravity<#1e>notify:resize<#1e>requ est
:colormap<#1e>notify:keymap<#1e>notify:selec tion<#1e>clear
:configure<#1e>notify :key<#1e>press :select ion<#1e>notify
:configure<#1e>request:key<#1e>release:selec tion<#1e>request
:create<#1e>notify:leave<#1e>notify:unmap<#1e> notify
:destroy<#1e>notify:map<#1e>notify:visibilit y<#1e>notify
:enter<#1e>notify:map<#1e>request event<#1e>mask '(or mask32 (list event<#1e>mask<#1e> class))Typemask", Sort String = "event<#1e>mask"> Provides a way to specify a set of bits for an event bitmask. Two ways of specifying the bits are allowed: by setting the event bits in a 32 bit mask, or by listing the keyword names of the event bits in a list. <|,"1<#1e>16"> event<#1e>mask<#1e>class '(member event*) Typemask<#1e>class", Sort String = "event<#1e>mask<#1e>class"> The elements of the type event<#1e>mask<#1e>class are keyword names that correspond to a particular bit in an event bitmask. event <#1f> One of the following: :button<#1e>1<#1e>motion:enter<#1e>window:pointer<#1e>motio n<#1e>hint
:button<#1e>2<#1e>motion:exposure:property<#1e>change
:button<#1e>3<#1e>motion:focus<#1e>change:resize<#1e>redirect
:button<#1e>4<#1e>motion:key<#1e>press:structure<#1e>notify
:button<#1e>5<#1e>motion:key<#1e>release:substructure<#1e>notify
:button<#1e>motion:keymap<#1e>state:substructure<#1e>redirect
:button<#1e>press:leave<#1e>window:visibility<#1e>change
:button<#1e>release:owner<#1e>grab<#1e>button
:colormap<#1e>change:pointer<#1e>motion make<#1e>event<#1e>keys event<#1e>maskFunctionevent<#1e>keys", Sort String = "make<#1e>event<#1e>keys"> Returns: event<#1e>keywords <#1f> Type list. Returns a list of event<#1e>mask<#1e>class keyword names for the event bits that are set in the specified event mask. event<#1e>mask <#1f> An event mask (type mask32). make<#1e>event<#1e>mask &rest keysFunctionevent<#1e>mask", Sort String = "make<#1e>event<#1e>mask"> Returns:
event<#1e>mask <#1f> Type mask32. Constructs an event mask from a set of event<#1e>mask<#1e>class keyword names. keys <#1f> event<#1e>mask<#1e>class keywords. font '(satisfies font<#1e>p)Type A text font. See Section 8, Fonts and Characters, for additional information. fontable '(or stringable font)Type A fontable is either a font object or the name of one of the fonts in the font database. font<#1e>props 'listTypeprops", Sort String = "font<#1e>props"> A list that contains alternating keywords and integers. gcontext '(satisfies gcontext<#1e>p)Typ e A graphics context. See Section 5, Graphics Contexts, for additional information. gcontext<#1e>key '(member type*)Typekey", Sort String = "gcontext<#1e>key"> A list of predefined types for use in gcontext processing. Various information for graphics output is stored in a graphics context (GC or GContext), such as foreground pixel, background pixel, line width, clipping region, and so forth. type <#1f> One of the following: <|,"1<#1e>17">:arc<#1e>mode:exposures:line<#1e>width
:background:fill<#1e>rule:plane-mask
:cap<#1e>style:fill<#1e>style :stipple
:clip<#1e>mask :font:subwindow<#1e>mode
:clip<#1e>x:foreground:tile
:clip<#1e>y:function:ts<#1e>x
:dash<#1e>offset :join<#1e>style:ts<#1e>y
:dashes:line<#1e>style grab<#1e>status '(member grab<#1e>type*) Typestatus", Sort String = "grab<#1e>status"> There are two kinds of grabs: active and passive. An active grab occu rs when a single client grabs the keyboard and/or pointer explicitly. Clients can also grab a particular keyboard key or pointer button in a window. The grab activates when the key or button is actually pressed, and is called a passive grab. Passive grabs can be very convenient for implementing reliable pop<#1e>up menus. grab<#1e>type <#1f> One of the following: :already<#1e>grabbed
:frozen
:invalid<#1e>time
:not<#1e>viewable
:success image<#1e>depth '(integer 0 32)Typedepth", Sort String = "image<#1e>depth"> Used in determining the depth of a pixmap, window, or image. The value specifies the number of bits deep that a given pixel has within a given pixmap, window, or image. index<#1e>size '(member :default 8 16)Typesize", Sort String = "index<#1e>size"> Used to control the element size of the destination buffer given to the translate function when drawing glyphs. If :default is specified, the size is based on the current font, if known; otherwise, 16 is used. int8 '(signed<#1e>byte 8)Type A signed integer value that is a maximum of eight bits long. A number of this type can have a range from -128 to 127. int16 '(signed<#1e>byte 16)Type A signed integer value that is a maximum of 16 bits long. A number of this type can have a range from -32,768 to 32,767. int32 '(signed<#1e>byte 32)Type A signed integer value that is a maximum of 32 bits long. A number of this type can have a range from -2,147,483,648 to 2,147,483,647. keysym 'card32Type Used as an encoding of a symbol on a keycap on a keyboard. It is an unsigned integer value represented in a maximum of 32 bits long. A keysym type can have a range from 0 to 4,294,967,295. mask16 ' card16Type A positional bitmask that contains 16 boolean flags. <|,"1<#1e>18">mask32 ' card32Type A positional bitmask that contains 32 boolean flags. modifier<#1e>key '(member modifier*)Typ ekey", Sort String = "modifier<#1e>key"> A keyword identifying one of the modifier keys on the keyboard device. modifier <#1f> One of the following: :shift:mod<#1e>2
:lock:mod<#1e>3
:control:mod<#1e>4
:mod<#1e>1:mod<#1e>5 modifier<#1e>mask '(or (member :any) mask16 (list modifier<#1e>key))Typemask", Sort String = "modifier<#1e>mask"> A bitmask or list of keywords that specifies a set of modifier keys. The keyword :any is equivalent to any subset of modifier key. pixarray '(or (array pixel (* *))Type
(array card16 (* *))
(array card8 (* *))
(array (unsigned<#1e>byte 4) (* *))
(array bit (* *))) Specifies a two<#1e>dimensional array of pixels. pixel '(unsigned<#1e>byte 32)Type An unsigned integer value that is a maximum of 32 bits long. This gives a pixel type a value range from 0 to 4,294,967,295. Useful values are dependent on the class of colormap being used. pixmap '(satisfies pixmap<#1e>p)Type A pixmap. See paragraph 4.8, Pixmaps, for additional information. pixmap<#1e>formatStructureformat", Sort String = "pixmap<#1e>format"> A structure that describes the storage format of a pixmap. The pixmap<#1e>format structure contains slots for depth, bits<#1e>per<#1e>pixel, and scanline<#1e>pad. The depth member indicates the number of bit planes in the pixmap. The bits<#1e>per<#1e>pixel member indicates the number of bits used to represent a single pixel. For X, a pixel can be 1, 4, 8, 16, 24, or 32 bits wide. As for bitmap<#1e>format, the scanline<#1e>pad member indicates how many pixels are needed to pad the left edge of the scan<#1e>line. depthSlot of pixmap<#1e>format Type: image<#1e>depth. The number of bit planes in the pixmap. bits<#1e>per<#1e>pixelSlot of pixmap<#1e>format Type: (member 1 4 8 16 24 32). The number of consecutive bits used to encode a single pixel. The default is 8. <|,"1<#1e>19">scanline<#1e>padSlot of pixmap<#1e>format Type: (member 8 16 32). The number of bits to left<#1e>pad the scan<#1e>line, which can be 8, 16, or 32. The default is 8. point<#1e>seq '(repeat<#1e>seq (int16 x) (int16 y))Typeseq", Sort String = "point<#1e>seq"> The point<#1e>seq type is used to define sequences of (x, y) pairs of points. The paired values are 16<#1e>bit, signed integer quantities. This gives the points in this type a range from -32,768 to 32,767. pointer<#1e>event<#1e>mask '(or mask32 (list pointer<#1e>ev ent<#1e>mask<#1e>class))Typeevent<#1e>mask", Sort String = "pointer<#1e>event<#1e>mask"> Provides a way to specify a set of bits for an event bitmask. Two ways of specifying the bits are allowed: by setting the event bits in a 32 bit mask, or by listing the keyword names of the pointer related event bits in a list. pointer<#1e>event<#1e>mask<#1e>class '(member event*) Typeevent<#1e>mask<#1e>class", Sort String = "pointer<#1e>event<#1e>mask<#1e>class"> A keyword name, for a pointer related event, that corresponds to a particular bit in an event bitmask. The set of names is a subset of the names in the type event<#1e>mask<#1e>class. event <#1f> One of the following: :button<#1e>1<#1e>motion:button<#1e>motion:leave<#1e>window
:button<#1e>2<#1e>motion:button<#1e>press:pointer<#1e>motion
:button<#1e>3<#1e>motion:button<#1e>release:pointer<#1e>motion<#1e> hint
:button<#1e>4<#1e>motion:enter<#1e>window
:button<#1e>5<#1e>motion:keymap<#1e>state rect<#1e>seq '(repeat<#1e>seq (int16 x) (int16 y) (card16 width) (card16 height))Typeseq", Sort String = "rect<#1e>seq"> rect<#1e>seq defines a four<#1e>tuple sequence of the form (x, y, width, height). The points x and y are signed, 16<#1e>bit quantities with a range from -32,768 to 32,767. The width and height values are unsigned, 16<#1e>bit quantities and range from 0 to 65,535. repeat<#1e>seq (&rest elts) 'sequenceTypeseq", Sort String = "repeat<#1e>seq"> A subtype used to define repeating sequences. <|,"1<#1e>20">resource<#1e>id 'card29Typeid", Sort String = "resource<#1e>id"> A numeric identifier that is assigned by the server to a server resource object. rgb<#1e>val '(float 0.0 1.0)Typeval", Sort String = "rgb<#1e>val"> An rgb<#1e>val is a floating<#1e>point value between 0 and 1 that specifies a saturation for a red, green, or blue additive primary. The 0 value indicates no saturation and 1 indicates full saturation. screen '(satisfies screen<#1e>p)Type A display screen. See Section 3, Screens, for further information. seg<#1e>seq '(repeat<#1e>seq (int16 x1) (int16 y1) (int16 x2) (int16 y2))Typeseq", Sort String = "seg<#1e>seq"> Defines sequences of (x1, y1, x2, y2) sets of points. The point values are 16<#1e>bit, signed integer quantities. This gives the points in this type a range from -32,768 to 32,767. state<#1e>mask<#1e>key '(or modifier<#1e>key (member button*)Typemask<#1e>key", Sort String = "state<#1e>mask<#1e>key"> A keyword identifying one of the display modifier keys or pointer buttons whose state is reported in device events. button <#1f> One of the following: :button<#1e>1:button<#1e>4
:button<#1e>2:button<#1e>5
:button<#1e>3 make<#1e>state<#1e>keys state<#1e>maskFunctionstate<#1e>keys", Sort String = "make<#1e>state<#1e>keys"> Returns:
state<#1e>keywords <#1f> Type list. Returns a list of state<#1e>mask<#1e>key symbols corresponding to the state<#1e>mask. A symbol belongs to the returned list if, and only if, the corresponding state<#1e>mask bit is 1. state<#1e>mask <#1f> A 16<#1e>bit mask of type mask16. make<#1e>state<#1e>mask &rest keysFunctionstate<#1e>mask", Sort String = "make<#1e>state<#1e>mask"> Returns:
mask <#1f> Type mask16. Returns a 16<#1e>bit mask representing the given state<#1e>mask<#1e> key symbols. The returned mask contains a 1 bit for each keyword. keys <#1f> A list of state<#1e>mask<#1e>key symbols. stringable '(or string symbol)Type Used for naming something. This type can be either a string or a symbol whose symbol<#1e>name is used as the string containing the name. The case of the characters in the string is ignored when comparing stringables. <|,"1<#1e>21">timestamp '(or null card32)Type An encoding of a time. nil stands for the current time. visual<#1e>infoStructureinfo", Sort String = "visual<#1e>info"> A structure that represents a visual type. The elements of this structure are id, class, red<#1e>mask, green<#1e>mask , blue<#1e>mask, bits<#1e>per<#1e>rgb, and colorm ap<#1e>entries. idSlot of visual<#1e>info Type: card29. A unique identification number. classSlot of visual<#1e>info Type: (member :direct<#1e>color :gray<#1e>scale :pseudo<#1e>color :static<#1e>color
:static<#1e>gray :true<#1e>color). The class of the visual type. red<#1e>mask, green<#1e>mask, blue<#1e>maskSlots of visual<#1e>info Type: pixel. The red<#1e>mask, green<#1e>mask, and blue<#1e>mask elements are only meaningful for the :direct<#1e>color and :true<#1e>color classes. Each mask has one contiguous set of bits with no intersections. bits<#1e>per<#1e>rgbSlot of visual<#1e>info Type: card8. Specifies the log base 2 of the approximate number of distinct color values (individually) of red, green, and blue. Actual RGB values are unsigned 16<#1e>bit numbers. colormap<#1e>entriesSlot of visual<#1e>info Type: card16. Defines the number of available colormap entries in a newly created colormap. For :direct<#1e>color and :true<#1e>color, this is the size of an individual pixel subfield. <|,"1<#1e>22">win<#1e>gravity '(member gravity*)Typegravity", Sort String = "win<#1e>gravity"> A keyword that specifies how to reposition a window when its parent is resized. gravity <#1f> One of the following: :center:north<#1e>west:static
:east:south:unmap
:north:south<#1e>east:west
:north<#1e>east:south<#1e>west If a parent window is reconfigured without changing its inside width or height, then all child windows move with the parent and are not changed. Otherwise, each child of the resized parent is moved, depending on the child's gravity attribute. See window<#1e>gravity, in paragraph 4.3, Window Attributes, for additional information. window '(satisfies window<#1e>p)Type A window. See Section 4, Windows and Pixmaps, for additional information. xatom '(or string symbol)Type A name that has been assigned a corresponding unique ID by the server. xat oms are used to identify properties, selections, and types defined in the X server. An xatom can be either a string or symbol whose symbol<#1e>name is used as the xatom name. The case of the characters in the string are significant when comparing xatoms. .