/[mcclim]/mcclim/Doc/Guided-Tour/guided-tour.tex
ViewVC logotype

Contents of /mcclim/Doc/Guided-Tour/guided-tour.tex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (hide annotations)
Mon Jan 30 16:14:01 2006 UTC (8 years, 2 months ago) by cfruhwirth
Branch: MAIN
File MIME type: application/x-tex
Move docs/guided-tour to Doc/Guided-Tour.
Add line-breaks to guided-tour.tex.
1 cfruhwirth 1.1 \documentclass[twocolumn,a4paper]{article}
2     \usepackage[dvips]{graphicx}
3     \usepackage{color} % Need the color package
4     \usepackage{listings}
5     %\usepackage{epsfig}
6     \title{\Huge A Guided Tour of CLIM, \\ Common Lisp Interface Manager}
7     \author{
8     2006 Update \\
9     Clemens Fruhwirth \texttt{<clemens@endorphin.org>} \\ The McCLIM Project
10     \bigskip \\
11     \begin{tabular}{ll}
12     \multicolumn{2}{c}{Original article\footnote{Published in Lisp Pointers 1991}} \\
13     Ramana Rao \texttt{<rao@xerox.com>} & Xerox Palo Alto Research Center \\
14     William M. York \texttt{<york@ila.com>} & International Lisp Associates, Inc. \\
15     Dennis Doughty \texttt{<doughty@ila.com>} & International Lisp Associates, Inc.
16     \end{tabular}
17     }
18    
19     \def\VRfont{\sffamily}
20    
21     \lstset{%
22     basicstyle=\small\sffamily,
23     keywordstyle=\small\sffamily,
24     stringstyle=\rmfamily,
25     commentstyle=\rmfamily\itshape,
26     frame=lines,
27     language=Lisp }
28    
29     \lstdefinestyle{framestyle}
30     {frame=lines}
31     \lstdefinestyle{inlinestyle}
32     {frame=none}
33    
34    
35     \makeatletter
36     \newcommand {\concept} [1] {{\sl #1}\index{#1}}
37     \newcommand {\term} [1] {{\sl #1}}
38     \newcommand {\code}[1]{{\sffamily #1}}
39     \newcommand {\CLIM}{{\small CLIM}}
40     \let\class\code
41     \let\method\code
42     \let\constant\code
43     \let\variable\code
44     \let\macro\code
45     \let\keyword\code
46     \makeatother
47    
48     \begin{document}
49     \maketitle
50     \begin{abstract}
51     \noindent The Common Lisp Interface Manager (\CLIM{}) provides a
52     layered set of facilities for building user interfaces. These
53     facilities include a portable layers for basic windowing, input,
54     output services, and mechanisms for constructing window types and user
55     interface components; stream-oriented input and output facilities
56     extended with presentations and context sensitive
57     input\footnote{Similar to the work pioneered in the Genera UI system};
58     and a gadget-oriented toolkit similar to those found in the X world
59     extended with support for look and feel adaptiveness. In this article,
60     we present an overview of \CLIM{}'s broad range of functionality and
61     present a series of examples that illustrates \CLIM{}'s power. The
62     article originally appeared in Lisp Pointers in 1991 and was updated
63     in 2006 by Clemens Fruhwirth.\footnote{The CLIM 2 specification
64     changed significant parts of \CLIM{} rendering legacy code
65     unusable. Clemens Fruhwirth has rewritten all examples and the
66     corresponding text section for the \CLIM{} 2 specification. In
67     addition, he restructured the whole article and added text sections
68     to provide additional insights into \CLIM{} concepts.} All examples
69     in this article have been developed with McCLIM{}\cite{mcclim}, a free
70     \CLIM{} implementation.
71     \end{abstract}
72    
73     \section*{Introduction}
74     Common Lisp is a language standard that has provided a broad range of
75     functionality, and that has, to a large degree, successfully enabled
76     the writing of truly portable Lisp programs. The emergence of CLOS and
77     the cleanup efforts of Ansi X3J13 have further enhanced the utility
78     and portability of Common Lisp. However, one major stumbling block
79     remains in the path of those endeavoring to write large portable
80     applications. The Common Lisp community has not yet provided a
81     standard interface for implementing user interfaces beyond the most
82     basic operations based on stream reading and printing.\footnote{Notice
83     that this sentence was written in 1991. Unfortunately, it is still
84     true 15 years later.}
85    
86     The Common Lisp Interface Manager addresses this problem by specifying
87     an interface to a broad range of services necessary or useful for
88     developing graphical user interfaces. These services include low level
89     facilities like geometry, graphics, event-oriented input, and
90     windowing; intermediate level facilities like support for Common Lisp
91     stream operations, output recording, and advanced output formatting;
92     and high level facilities like context sensitive input, an adaptive
93     toolkit, and an application building framework.
94    
95     \CLIM{} will eventually support a large number of window environments
96     including X Windows, Mac OS X and Microsoft Windows. \CLIM{} is
97     designed to exploit the functionality provided by the host environment
98     to the degree that it makes sense. For example, \CLIM{} top level
99     windows are typically mapped onto host windows, and input and output
100     operations are ultimately performed by host window system
101     code. Another example is that \CLIM{} supports the incorporation of
102     toolkits written in other languages. A uniform interface provided by
103     \CLIM{} allows Lisp applications programmers to deal only with Lisp
104     objects and functions regardless of their operating platform.
105    
106     An important goal that has guided the design of \CLIM{} has been to
107     layer the specification into a number of distinct
108     facilities. Furthermore, the specification does not distinguish the
109     use of a facility by higher level \CLIM{} facilities from its use by
110     \CLIM{} users. For example, the geometry substrate, which includes
111     transformations and regions, is designed for efficient use by the
112     graphics and windowing substrates as well as by \CLIM{} users. This
113     means that, in general, a \CLIM{} user can reimplement higher level
114     \CLIM{} facilities using the interfaces provided by lower level
115     facilities.
116    
117     This modular, layered design has a number of benefits. The \CLIM{}
118     architecture balances the goal of ease of use on one hand, and the
119     goal of versatility on the other. High level facilities allow
120     programmers to build portable user interfaces quickly, whereas lower
121     level facilities provide a useful platform for building toolkits or
122     frameworks that better support the specific needs or requirements of a
123     particular application.
124    
125     For example, \CLIM{}'s application framework and adaptive toolkit
126     allow users to develop applications that automatically adopt the look
127     and feel of the host's environment. (We often call this
128     ``adaptiveness,'' ``look and feel independence,'' or occasionally more
129     picturesquely, ``chameleon look and feel''.) However, many users may
130     need or want to define a particular look and feel that stays constant
131     across all host environments (we call this "portable look and
132     feel"). Such users can circumvent the look and feel adaptiveness
133     provided by \CLIM{}, while still using most of the application
134     framework facility and other high level \CLIM{} facilities like
135     context sensitive input. Furthermore, using the lower level facilities
136     of \CLIM{}, they can develop portable toolkit libraries that define
137     and implement their own particular look and feel. For instance, the
138     \CLIM{} user can implement new gadget types on top of the drawing
139     primitives and treat them equally to the build-in gadget types.
140    
141     We will use the term \concept{CLIM implementor} for the party
142     implementing low-level and high-level parts according to the \CLIM{}
143     specification, \concept{CLIM programmer} for the party that will use
144     the facilities provided by the implementor, and \concept{CLIM user}
145     for the party that will use the programs provided by the programmer.
146    
147     The next section presents an overview of the functionality provided by
148     \CLIM{} facilities.
149    
150     \section{Overview of Functionality}
151    
152     Figure \ref{clim-facilities} shows the various aspects of a host
153     environment in which \CLIM{} lives as well as the various elements
154     provided by \CLIM{}. Below we briefly describe a number of \CLIM{}'s
155     areas of functionality. Later sections will illustrate many of these
156     components.
157    
158     \paragraph*{Geometry} \CLIM{} provides points, rectangles, and
159     transformations; and functions for manipulating these object types.
160    
161     \begin{figure*}
162     \begin{center}
163     \input{techno-dep.pstex_t}
164     \end{center}
165     \caption{An Overview of \CLIM{} facilities}\label{clim-facilities}
166     \end{figure*}
167    
168     \paragraph*{Graphic substrate} \CLIM{} provides a portable interface
169     to a broad set of graphics functions for drawing complex geometric
170     shapes.
171    
172     \paragraph*{Windowing substrate} \CLIM{} provides a portable layer for
173     implementing sheets (windows and other window-like objects).
174    
175     \paragraph*{Extended Streams} \CLIM{} integrates the Common Lisp
176     Stream I/O functionality with the \CLIM{} graphics, windowing, and
177     panes facilities. Next to ordinary text, the programmer can send a
178     button, a picture or any other arbitrary widget to a \CLIM{} output
179     stream and \CLIM{} will display the widget in the sheet associated
180     with the output stream.
181    
182     \paragraph*{Output Recording} \CLIM{} provides output recording for
183     capturing all output done to an extended stream and automatically
184     repainting it when necessary.
185    
186     \paragraph*{Formatted Output} \CLIM{} provides a set of high-level
187     macros that enable programs to produce neatly formatted tabular and
188     graphical displays easily.\footnote{This also includes Graph
189     Formatting}
190    
191     \paragraph*{Presentations} \CLIM{} provides the ability to associate
192     semantics with output, such that Lisp objects may be retrieved later
193     via user gestures (e.g. mouse clicks) on their displayed
194     representation. This context sensitive input is modularly layered on
195     top of the output recording facility and is integrated with the Common
196     Lisp type system. A mechanism for type coercion is also included,
197     providing the basis for powerful user interfaces.
198    
199     \paragraph*{Panes} \CLIM{} provides \concept{panes} that are analogous
200     to the gadgets or widgets of toolkits like the X toolkit, GTK or Mac
201     OS X's toolkit.
202    
203     Supported pane types include layout panes for arranging other panes,
204     gadget panes for presenting users with feedback information or
205     mechanisms for invoking application behavior, and application panes
206     for displaying and allowing users to interact with application data.
207    
208     \paragraph*{Look and Feel Adaptiveness} \CLIM{} supports look and feel
209     independence by specifying a set of abstract gadget pane
210     protocols. These protocols define a gadget in terms of its function
211     and not in terms of the details of its appearance or
212     operation. Application that use these gadget types and related
213     facilities will automatically adapt to use whatever toolkit is
214     available and appropriate for the host environment. In addition,
215     portable Lisp-based implementations of the abstract gadget pane
216     protocols are provided.\footnote{McCLIM does not support look and feel
217     adaptiveness at the moment except for the experimental port for Mac
218     OS X. Hence, McCLIM mostly uses this portable Lisp-based
219     implementation.}
220    
221     \paragraph*{Application Building} \CLIM{} provides a set of tools for
222     defining application frames. These tools allow the programmer to
223     specify all aspects of an application's user interface, including pane
224     layout, interaction style, look and feel, and command menus and/or
225     menu bars.
226    
227     \paragraph*{Commands} \CLIM{} supports the separation of command
228     execution and command invocation. A \CLIM{} user can invoke commands
229     either via typing it into an interactor, clicking on a menu entry or
230     implicitly invoking a presentation-translator by clicking on a
231     presentation. Commands can also be invoked explicitly by the
232     programmer.
233    
234     \paragraph*{Dialogs and Incremental Update} Incremental Redisplay goes
235     a bit further than Output Recording. With Incremental Redisplay, an
236     output record can not only reproduce content that was written to a
237     stream, the \CLIM{} programmer can also attach the code that generated
238     the content to the content itself. Whenever necessary, the application
239     programmer can ask an output stream to update itself. \CLIM{} will
240     query all code generators and in case, replace obsolete content.
241    
242     \noindent\hrulefill
243    
244     \noindent These are a lot of facilities to explore. The most
245     systematically way -- exploring from the most low-level to the most
246     high-level -- would also be the most longsome. Therefore, we start
247     with showing several facilities in action with the most fundamental
248     example in the realm of programming: Hello World.
249    
250     \section{Our first application}
251    
252     We will spend a few lines of code for the trivial Hello World example
253     to give the reader a test case to verify his \CLIM{} setup. It also
254     serves as a point of reference from where the reader can start his
255     explorations for more challenging \CLIM{} facilities. We do not try to
256     elaborate the \CLIM{} concepts in detail here, but simply use them
257     with a brief discussion. The confused reader may hope for a more
258     in-depth explanation in the following section. Please regard
259     \concept{pane}, \concept{application frame}, \concept{sheet},
260     \concept{sheet hierarchy}, \concept{graft} and \concept{top-level
261     loop} as terms we will discuss later.
262    
263     Also, we conduct excessive \CLIM{} specification referencing in
264     footnotes. The motivation for this is to show that all the relevant
265     information can be found in the \CLIM{} 2
266     specification\cite{clim-spec}. Before a good \CLIM{} programmer can
267     master any \CLIM{} concept, he has to get used to the style of writing
268     of the specification first as this is the most relevant work for
269     \CLIM{}. The best we can do in this context is to provide pointers and
270     references and hope that the interested reader starts to explore the
271     surrounding text sections on his own.
272    
273     The central element of \CLIM{} application programming is the
274     \concept{application-frame}. An application frame is defined via
275     \code{define-application-frame}.\footnote{See Section 28.2 ``Defining
276     and Creating Application Frames'' in \cite{clim-spec}.} Here comes
277     the application frame for Hello World:
278     \lstset{style=inlinestyle}
279     \lstinputlisting{hello-world-def-app}
280    
281     \begin{figure*}
282     \lstset{style=framestyle}
283     \lstinputlisting{hello-world-handle-repaint}
284     \caption{\method{handle-repaint} for \class{hello-world-pane}}\label{hello-world-repaint}
285     \end{figure*}
286     Its basic syntax is similar to \code{defclass} because
287     \code{define-application-frame} also generates classes. In this case,
288     it creates a frame class \class{hello-world} that has no superclass
289     except \class{frame} which is added automatically.
290    
291     With \code{:pane}, we define a \concept{top-level-pane} that becomes
292     the content of the fresh window that belongs to an application
293     frame. But sometimes, an application frame is swallowed by another
294     application and only space in an other existing window is
295     reserved. For instance, a web site management tool might swallow a
296     text editor, so the user has the option to edit web sites without
297     switching to another application.
298    
299     % \footnote{The graft is the root of a sheet hierarchy and on most
300     % windowing system, all children of a graft are mapped to windows.}
301     % With elaborating on details, this means that the content of the
302     % top-level-pane becomes the content of the application
303     % window.\footnote{This is not 100\% correct. A frame might decorate
304     % the top-level-pane with a menu-bar or other refinements. The pane
305     % adopted by the graft is then a composite pane containing a
306     % menu-bar and the original top-level-pane.}
307    
308     The list given after the \keyword{:pane} option is a form which is
309     evaluated when an instance of the \class{hello-world} class is
310     created. We use \method{make-pane} to construct a pane as the
311     top-level-pane for frame instances. \method{make-pane} is a
312     constructor for panes.\footnote{See Section 29.2 ``Basic Pane
313     Construction'' in \cite{clim-spec}.} We can treat it as
314     \code{make-instance} especially made for pane classes. Let us have a
315     look at the definition of \class{hello-world-pane}.
316    
317     \lstset{style=inlinestyle} \lstinputlisting{hello-world-defclass}
318    
319     The one and only superclass of \class{hello-world-pane} is
320     \class{clim-stream-pane}\footnote{See Section 29.4 ``CLIM Stream
321     Panes'' in \cite{clim-spec}.}. As there are no additional slot, an
322     experience CLOS user might have correctly guessed that we will use
323     \class{hello-world-pane} solely for method specialization.
324    
325     But before we do that, let us have a look what we have actually
326     inherited from \class{clim-stream-pane}\footnote{Internal classes
327     removed from Listing}:
328    
329     \pagebreak % formathack
330     \lstset{style=inlinestyle}
331     \begin{lstlisting}
332     CLIM-USER> (describe (find-class
333     'clim-stream-pane))
334     DIRECT-SUPERCLASSES:
335     PERMANENT-MEDIUM-SHEET-OUTPUT-MIXIN
336     STANDARD-REPAINTING-MIXIN
337     STANDARD-EXTENDED-INPUT-STREAM
338     STANDARD-EXTENDED-OUTPUT-STREAM
339     STANDARD-OUTPUT-RECORDING-STREAM
340     SHEET-MULTIPLE-CHILD-MIXIN
341     BASIC-PANE
342     \end{lstlisting}
343    
344     \class{basic-pane} is the foundation of all pane classes. It provides
345     reasonable defaults for all protocol methods and inherits from the
346     protocol class \class{pane}. In turn, \class{pane} inherits from
347     \class{basic-sheet}. Hence, all panes we construct via
348     \class{basic-pane} automatically adhere to the sheet protocol.
349    
350     % The standard extended-input provides \class{clim-stream-pane} with a
351     % concept called \concept{command-inversion}. This concept allows the
352     % treatment of events as if they were coming from a stream with
353     % blocking reads.
354    
355     % The permanent-sheet-output-mixin class delivers all methods for the
356     % \concept{output protocol} \footnote{See Section 8.3 ``Output
357     % Protocol'' in \cite{clim-spec}}. This protocol used for delivering
358     % output to the user's screen. The special feature of this mixin is
359     % that the output medium is always present, it's permanent. That
360     % means, there is always a screen on which graphic operations can be
361     % carried out. In contrast, there are also output classes, that does
362     % not guarentee an output medium, but more on that later.
363    
364     Our \class{hello-world-pane} needs some methods to be useful. With
365     \method{handle-repaint} in \figurename~\ref{hello-world-repaint}, we
366     participate in the \concept{repaint protocol}.\footnote{See Section
367     8.4 ``Repaint Protocol'' in \cite{clim-spec}} This method has two
368     tasks: paint the pane with the pane's background and draw the greeting
369     of \code{*application-frame*} in the center of the pane. The
370     \code{hello-world} frame instance is automatically available in the
371     context of \method{handle-repaint} via the dynamically scoped variable
372     \code{*application-frame*} and so it is possible to use the accessor
373     \code{greeting} to obtain the instance's slot content.
374    
375     Two functions are needed to see this code in action:
376     \code{make-application-frame} and \code{run-frame-top-level}. The
377     former is a constructor for instances of frame classes, the latter for
378     running the \concept{top-level loop} of the application frame. The
379     top-level loop is used for command reading, execution and displaying
380     results. But all we need to know for the moment is that it makes the
381     frame visible before entering the loop.
382     \lstset{style=inlinestyle}
383     \begin{lstlisting}
384     (run-frame-top-level
385     (make-application-frame 'hello-world))
386     \end{lstlisting}
387     This completes the Hello World example. In the next section, we catch
388     up to the details we skipped in this example.
389    
390     \section{Basic Facilities}
391    
392     \subsection{Geometry}
393    
394     To \CLIM{}, geometry means \concept{regions}. A region is either bound
395     or unbound and has a dimensionality of either zero, one or two. That
396     corresponds to a point, a path or an area respectively. Regions can be
397     compared (region predicate protocol\footnote{\CLIM{} relays heavily on
398     CLOS. In CLOS, the term \concept{protocol} means a set of generic
399     functions that together form a coherent interface. A protocol
400     specification does not only include the syntactic details of the
401     function names and the number of function arguments, but also the
402     functions purpose and the semantic of the return values (and/or side
403     effects) must be given in a textual specification.}) and composed
404     (region composition protocol).
405    
406     Every bounded region has a \concept{bounding rectangle}. It is the
407     smallest rectangle that contains every point in the region. The
408     bounding rectangle of every bounded region can be accessed via the
409     \concept{bounding rectangle protocol}.
410    
411     \CLIM{} supports \concept{affine transformations} of regions. Such
412     transformations can move, stretch and rotate a region. A
413     transformation is affine when every straight line remains straight
414     after transformation. Transformations can be composed arbitrarily. The
415     programmer can attach transformations to mediums and panes. In layout
416     panes, \CLIM{} uses transformation to map the coordinates of children
417     panes to the coordinate system of its parents. All drawing settings
418     can be changed permanently, or in the context of a
419     \macro{with-drawing-options} macro temporarily.
420    
421    
422     \subsection{The Windowing Substrate}
423    
424     \CLIM{} does not directly talk to the window system. Instead, \CLIM{}
425     is layered on top of a windowing substrate\footnote{former Silica}.
426     This substrate is a middleware between \CLIM{} on one side and the
427     host window system on the other. This middleware layer provides a
428     portable windowing model that insulates higher levels of \CLIM{} and
429     \CLIM{} programmers from the details of the host window system. From
430     the perspective of a \CLIM{} programmer, talking to the window system
431     is equal to talking to this abstraction layer. The implementation
432     details are hidden in \concept{backends}, like in McCLIM the CLX
433     backend, which hides X11 details, or the beagle backend, which hides
434     details for Mac OS X's toolkit. These backends will use the services
435     of a host window system to provide efficient windowing, input and
436     output facilities. Thanks to this middleware, \CLIM{} is portable
437     across different host windowing systems.
438    
439     This framework allows uniform treatment of the following GUI building
440     blocks:
441     \begin{itemize}
442     \item Windows like those in X, Mac OS X and Microsoft Windows.
443     \item Gadgets typical of toolkit layers, such as GTK, QT or Mac OS X's
444     toolkit. The backend provides a frame manager which takes care of
445     mapping the abstract gadget types found in \CLIM{} to appropriate
446     gadget with a native look and feel.
447     \item Structured graphics like output records and an application's
448     presentation objects
449     \end{itemize}
450    
451     The central abstraction specified by \CLIM{} is the \concept{sheet}. A
452     sheet is a surface that can be painted on and to which input gestures
453     can be directed, and that lives in a hierarchy of other such objects.
454     To get used to the notation of sheets, you can think of them as
455     swallowable windows.
456    
457     The fundamental notion in \CLIM{} is the nesting of sheets within
458     another sheet called a windowing relationship. In a windowing
459     relationship, a parent sheet provides space to or groups a number of
460     other children sheets. The \concept{sheet protocols} specify
461     functionality for constructing, using, and managing hierarchies of
462     sheets.
463    
464     Sheets have the following properties:
465     \begin{description}
466     \item[parent/children:] a sheet is part of a windowing hierarchy and
467     maintains links to its parent and its children.
468     \item[coordinate system:] a sheet has its own coordinate system that
469     might have a different scaling or orientation than its parent.
470     \item[transformation:] via a sheet transformation these differing
471     sheet coordinate systems are mapped into coordinate system of their
472     parents.
473     \item[clipping region:] defines an area within a sheet's coordinate
474     system that indicates the area of interest.
475     \end{description}
476    
477     \paragraph*{Window hierarchies} Sheets participate in a number of
478     protocols. The windowing protocols describes the relationship between
479     sheets. Every sheet has a parent, a sheet might have one or more
480     children. A sheet can be adopted by a parent sheet and disowned later.
481     A sheet is grafted when it is connected to a \concept{graft} either
482     directly or through it's ancestors. A graft is a special kind of sheet
483     that stands in for a host window, typically a root window (i.e. screen
484     level). A sheet is attached to a particular host window system by
485     making it a child of an associated graft. A host window will be
486     allocated for that sheet; the sheet will then appear to be a child of
487     the window associated with the graft.
488    
489     Sheet hierarchies are displayed and manipulated on particular host
490     window systems by establishing a connection to that window system and
491     attaching them to an appropriate place in that window system's window
492     hierarchy. Ports and grafts provide the functionality for managing
493     this process. A port is a connection to a display service that is
494     responsible for managing host window system resources and for
495     processing input events received from the host window system.
496    
497     \paragraph*{Window input} The input architecture of the windowing
498     substrate allows sheets to receive any window event from the host
499     windowing system. The event class hierarchy descends from the class
500     \code{event} to \code{device-event} (including all keyboard and mouse
501     actions), \code{window-event} (window-size-changed and window-repaint
502     events), \code{window-manager-events} (window-deleted) to artificial
503     \code{timer-events}. See 8.2 ``Standard Device Events'' in
504     \cite{clim-spec}.
505    
506     The function pair \code{dispatch-event} and \code{handle-event} is the
507     center of all event handling. \code{dispatch-event} is intended to be
508     called when an event is to be dispatched to a client either
509     immediately or queued for later processing in an event queue. On the
510     other side, \code{handle-event} is intended for further
511     specialization, so the application developer can implement special
512     policies for selected events. For instance, when a sheet notices
513     through a \code{window-configuration-event} that the sheet's size
514     changed, it might redo its layout for its children panes.
515    
516     % There are two mixins that specialize on the
517     % \code{window-repaint-event} class as event argument to
518     % dispatch-event. The mixins are named standard-repaint-mixin and
519     % immediate-repainting-mixin. The first queues the repaint events when
520     % they arive via dispatch-event and redirect calls to handle-event
521     % with repaint events to the method handle-repaint. The latter mixin
522     % also redirects handle-event to handle-repaint for repaint events,
523     % but in contrast to the former it also immediately calls
524     % handle-repaint for any events ariving via dispatch-event. See Figure
525     % \ref{fig1}.
526    
527     % \paragraph*{The repaint protocol} By demonstrating the use of
528     % handle-event with the repaint mixins, we have actually shown smaller
529     % protocol at work: the \concept{repaint protocol}. It's usually
530     % triggered by events generated from the host window system via the
531     % handle-event mechanism, but the \CLIM{} programmer can also trigger
532     % a repaint manually via the \code{repaint-sheet} function. The
533     % programmer should specialize on handle-repaint for his own classes.
534     % We have done that in the Hello World example.
535    
536     \paragraph*{Window output}
537    
538     All drawing operation happen on a \concept{medium}. This object
539     captures the state of the drawing like foreground, background, line
540     style, and the transformation which is applied to the coordinates
541     before drawing. Every medium is associated with a sheet. In turn, a
542     sheet must be associated with a medium whenever drawing operation
543     should be executed. Many \CLIM{} sheets are associated with a medium
544     permanently. \code{sheet-medium} obtains the medium associated with a
545     sheet.
546     % \footnote{Notice that the \CLIM{} specification \cite{clim-spec}
547     % specifies draw-text, draw-line, draw-rectangle, etc. as functions
548     % that operate on mediums. McCLIM names these functions
549     % medium-draw-text, medium-draw-line, medium-draw-rectangle, and so
550     % on. The functions that are available in McCLIM without the
551     % ``medium-'' prefix operate on sheets. These are trampoline
552     % functions that call the appropriate medium-prefixed function on
553     % the sheet's medium. According to the McCLIM authors, this is done
554     % for optimization.}
555    
556     The graphic output capabilities of sheets range from simple line style
557     and text style customization over rendering various geometrical
558     shapes, a color model capable of doing alpha blending, composable
559     affine transformations to pattern, stencil and tiling filling, and
560     pixmaps usage. The features of the \concept{output protocol} are
561     specified briefly in Section 8.3 ``Output Protocol''and more precisely
562     in Chapters 10-14 of \cite{clim-spec}.
563    
564     \CLIM{} lives in idealized world in terms of graphics operations. A
565     \CLIM{} programmer can use an infinitely long and wide drawing pane
566     with an arbitrary precise resolution and continuously variable amount
567     of opacity. As rendering devices with these properties are rare these
568     days, we need to render the idealized graphic description to a device
569     with finite size and a fixed drawing precision. The rendering rules
570     are specified in Section 12.4 ``Rendering Conventions for Geometric
571     Shapes''of \cite{clim-spec}.
572    
573     \section{Building Applications}
574    
575     In this section, we explain a number of the necessary ingredients for
576     building applications in \CLIM{}. We will illustrate frames, panes,
577     and simple commands with two examples: a color editor and a simple
578     line and text drawing program.
579    
580     \subsection{Application Frames}
581    
582     Frames are the central abstraction defined by the \CLIM{} interface
583     for presenting an application's user interface. Many of the high level
584     features and facilities for application building provided by \CLIM{}
585     can be conveniently accessed through the frame facility.
586    
587     Frames are typically displayed as top level windows on a desktop.
588     \concept{Frame managers} provide the machinery for realizing frames on
589     particular host window systems. A frame manager acts as an mediator
590     between the frame and what is typically called a desktop manager, or
591     in X terminology, a window manager. The \concept{frame manager} is
592     responsible for attaching the pane hierarchy of a frame to an
593     appropriate place in a sheet hierarchy (and therefore to a host window
594     system window hierarchy) when the frame is adopted.
595    
596     To build a user interface, an application programmer defines one or
597     more frames classes. These frame classes define a number of frame
598     properties including application specific state and a hierarchy of
599     panes (i.e. user interface gadgets and regions for interacting with
600     the users). Frame classes also provide hooks for customizing
601     application behavior during various portions of the frame protocol.
602     For example, an \keyword{:after} method on generic functions in the
603     frame protocol can allow applications to manage application resources
604     when the frame is made visible on some display server.
605    
606     \CLIM{} is able to show dialog windows, but the code that brings them
607     up is usually quite different from the code that is used to generate
608     the content of application frames. This is unusual for a windowing
609     toolkit as most of them unify the generation of dialog content and
610     content of other windows types.
611    
612     \CLIM{} generates a dialog with the appropriate input gadget as
613     consequence of a series of input requests. Thanks to the stream
614     facility, the programmer can actually request input synchronously with
615     a blocking read request. He does not have to take care of
616     asynchronously handling confirmation or cancel button clicks. For
617     instance, the programmer requests a string from the user and the user
618     is presented with a prompt, an editable text field, and two buttons
619     for confirmation and canceling. Only after the user hit the
620     confirmation button, the string requesting function returns and the
621     programmer can directly use the function's return value which is the
622     user provided string. A cancel button click is handled via throwing an
623     abort tag.
624    
625     From the callers perspective, an attempt to separate application
626     frames and dialogs could be: a dialog window itself is side-effect
627     free with respect to the application state and therefore the whole
628     sense of calling a dialog creation routine must arise from the values
629     it returns. For example, the code that modifies the state of the text
630     editor in a text-replace operation does not rest with the callback
631     code of the Ok button in the dialog. This task rests with the code
632     that is executed after the dialog returns its values, namely the code
633     of the Search/Replace command.
634    
635     % \footnote{This isn't a sharp distinction. We can also reinterprete
636     % an application frame as something resulting from a command in
637     % progress at a higher level. For instance, assume the application
638     % frame to be the intermediate dialog resulting from the click on
639     % your text editor icon of the desktop's launch menu/button, or to
640     % be the result from typing the application name in your shell. A
641     % more nifty example would be a text editor that allows embedded
642     % graphics which can be edited in-place by graphics editor. The text
643     % editor's application frame would then use another the graphic
644     % editor's application frame intermediately returning the modified
645     % graphic object.}
646    
647     An intermediate dialog is something that is brought up to collect
648     additional information for (or before) an operation. When the user
649     selects the ``Search'' command, he is queried for a search string in
650     an additional dialog window; probably offering other search options
651     like case insensitive search or backwards search. This is done in a
652     synchronous manner, blocking until the requested input is made
653     available by the user.
654    
655     % The notation of sheets already capture the idea of windows.
656     % Remember, sheets are drawable entities that can receive user input.
657     % In fact, the entire screen area is also represented as sheet. The
658     % sheet representing the whole screen real-estate is named
659     % \concept{graft} in \CLIM{}\footnote{In X terminology, a graft would
660     % be called root window.}. To create a new window, we have to order
661     % a graft to adopt a new sheet as its children. The new sheet is
662     % inserted into the sheet hierarchy below the graft (the sheet is said
663     % to be \concept{grafted}). But actually, we rarely do it that way.
664    
665     % \CLIM{} provides a higher level abstraction of windows and what
666     % their purpose are. In \CLIM{}, we either have application frames or
667     % intermediate dialogs.
668    
669     An application frame is an interface that provides the user with a
670     variety of commands to choose as his next step. For instance, the user
671     may choose from commands like Open, Save, Search, or Quit. The frame
672     is a long-living GUI object compared to dialogs and there is no linear
673     execution path as there is in after a dialog as the user is free to
674     select any commands he likes as next step.
675    
676     Hence, the synchronous programming pattern for dialogs is more
677     convenient because after dialog confirmations there is a predetermined
678     path of execution, while an application frame has to be prepared to
679     handle an arbitrary sequence of commands.
680    
681     % In contrast to dialogs, application frames tend to life longer than
682     % dialogs. Hence, application frames are usually required to maintain
683     % some state of some form. This is also the reason why
684     % \method{define-application-frame} was implemented on top of
685     % \macro{defclass}. A dialog does not need to maintain state as they
686     % are disposed too quickly.\footnote{They do have a state but this
687     % state is not important to the programmer as it mostly consist of
688     % state of the input gadgets, like the content of a text input
689     % field. The amount of information contained in there is usually
690     % neglectible, so we do not speak of state management here.}
691    
692     % \paragraph*{Frame Managers} One important function provided by a
693     % frame manager is to adapt a frame to the look and feel of the host
694     % window manager. Before the top-level loop of a frame is entered, the
695     % frame is adopted by a frame manager provided by a \CLIM{} backend.
696    
697    
698     \subsection{Panes}
699    
700     An application frame constructs its pane tree by specifying a
701     top-level pane in \macro{define-application-frame}. This pane is
702     usually a layout pane that contains more gadget and/or layout panes as
703     its children. With the help of layout panes, a pane hierarchy can be
704     constructed. The top-level pane (and the whole hierarchy when its a
705     layout pane) is created when the application frame is adopted by a
706     frame manager and made visible to the user. The programmer can compose
707     an interface consisting of pre-defined gadget panes, layout panes, or
708     application-specific panes. \CLIM{} panes are rectangular sheets that
709     are analogous to the gadgets or widgets of other toolkits.
710    
711     Panes and sheets as defined by the windowing substrate have in common
712     that they are associated with a region on screen, a parent, and
713     optional children. They differ in their usage of the input and output
714     capabilities. A sheet is passive and intended for others to be used,
715     while a pane already contains this active part. This relationship
716     leads that panes are implemented as subclasses of \class{basic-sheet}
717     augmenting the class with an active part. For instance, a button-pane
718     actively draws its own button representation on its allotted screen
719     area and a click on the correct button area triggers a callback for
720     the button. A composite pane lays out its children elements and
721     request them to draw themselves onto specific screen regions.
722    
723     \CLIM{} comes with a set of predefined gadget panes. They consist of
724     push-button, toggle-button, slider, radio-box, text-field, text-editor
725     panes ready for use by the \CLIM{} application programmer. These
726     gadgets might be remapped to native system gadgets by the frame
727     manager, so a native look and feel is possible.\footnote{Only possible
728     in McCLIM with the experimental beagle backend for Mac OS X.}
729    
730     Each gadget pane class is associated with a set of generic functions
731     that as callbacks in traditional toolkits. For example, a pushbutton
732     has an ``activate'' callback method which is invoked when its button
733     is pressed. For this particular callback, a method named
734     \method{activate-callback} is invoked per default and a \CLIM{}
735     programmer can provide a specialized method to implementation
736     application specific behavior for a subclassed button-pane. But except
737     in the case where the programmer needs a lot of buttons with related
738     behavior, creating a subclass for changing a single specific callback
739     is not economical. Hence upon gadget creation, the programmer can
740     specify an alternative callback method for all callback available. By
741     providing the \keyword{:activate-callback} initarg, the programmer can
742     change the callback to any regular or generic function. By convention,
743     all callbacks can be changed by providing an initarg keyword equal to
744     the callback's name. See Chapter 30 in \cite{clim-spec} for a listing
745     and description of available callbacks.
746    
747     \CLIM{} also provides composite and layout panes. These pane types are
748     used for aggregating several children panes into a bigger single pane
749     that has a layout according to the requested directives. For example,
750     \CLIM{} provides two pane classes, \class{hbox-pane} and
751     \class{vbox-pane}, that lay out their children in horizontal rows or
752     vertical columns respectively. The parent/child relations are managed
753     via the sheet's windowing protocol. If the user interface does not
754     change in ways unpredictable in advance (as in a user interface
755     builder for instance), the program does not have to do hierarchy
756     management via the windowing protocol. He is provided with a set of
757     convenience macros that allows elegant interfaces composed simply by
758     wrapping the respective pane construction code into the convenience
759     macros.
760    
761     Application pane classes can be used for subclassing. They can be used
762     to present application specific data -- for instance by specializing
763     \method{handle-repaint} -- and manage user interactions -- for
764     instance by specializing \method{handle-event}.
765    
766     \subsection{Commands}
767    
768     Most applications have a set of operations that can be invoked by the
769     user. In \CLIM{}, the command facility is used to define these
770     operations. Commands support the goal of separating an application's
771     user interface from its underlying functionality. In particular,
772     commands separate the notion of an operation from the details of how
773     the operation is invoked by the user.
774    
775     Application programmers define a command for each operation that they
776     choose to export as an explicit user entry point. A command is defined
777     to have a name and a set of zero or more operands, or arguments. These
778     commands can then be invoked using a variety of interaction
779     techniques. For example, commands can be invoked from menu, keyboard
780     accelerators, direct typein, mouse clicks on application data, or
781     gadgets.
782    
783     The commands are processed in a REPL-like loop. Every application
784     frame has its own running top-level loop specified via
785     \keyword{:top-level} in \method{define-application-frame}. For a
786     \CLIM{} application, it is rarely necessary to change the default top
787     level loop.
788    
789     The top-level loop becomes visible when an interactor-pane is added to
790     the user interface. Here the \CLIM{} user gains direct access to the
791     command loop. The loop steps are similar to read-eval-print:
792    
793     \begin{enumerate}
794     \item Read a command.
795     \item Execute the command.
796     \item Run the \concept{display function} for each pane in the frame
797     associated with the top-level loop as necessary.
798     \end{enumerate}
799    
800     Whenever a command is invoked other than by typing, an appropriate
801     command-invoking text appears after the command prompt
802     nonetheless. Here, the user can directly see how his commands are
803     synthesized from other invocation methods like pointer clicks or menu
804     item selections.
805    
806     \section{Simple applications}
807    
808     \subsection{Color Editor} In this next example, we define a frame for
809     color selection by manipulating their red, green, and blue components
810     separately. This example illustrates the use of gadget panes provided
811     by \CLIM{}. In the code in Figure \ref{fig-color-editor}, we define an
812     application frame using \method{define-application-frame}. As said
813     before, the syntax of this macro is similar to \class{defclass}. It
814     defines a new frame class which automatically inherits from the class
815     \class{frame} which provides most of the functionality for handling
816     frames.
817    
818     One requirement must be fulfilled by all frame definitions: code to
819     generate a pane hierarchy must be supplied. The \keyword{:pane} option
820     is the simplest way to supply this code. \class{hello frame}
821     constructs a hierarchy with only one application pane via
822     \method{make-pane}. The pane hierarchy of color editor is more
823     interesting.
824    
825     Every pane can request space via its initarg. A request for space
826     allocation is specified as a preferred size (\keyword{:height},
827     \keyword{:width}), a maximum size (\keyword{:max-height},
828     \keyword{:max-width}), and a minimum size (\keyword{:min-width},
829     \keyword{:max-width}). The special constant \constant{+fill+} can be
830     used to indicate the tolerance for any width or height.
831    
832     The color editor frame uses three application slots for storing the
833     current RGB values as well as two panes for showing the currently
834     selected colors. The variable \variable{*application-frame*} is
835     dynamically scoped and is defined in any event handler as well as for
836     all code that is evaluated in the context of the \keyword{:pane(s)}
837     frame option.
838    
839     \begin{figure*} \lstset{style=framestyle}
840     \lstinputlisting[firstline=7]{color-editor.lisp}
841     \caption{Color Editor}\label{fig-color-editor}
842     \end{figure*}
843    
844     The code provided in the \keyword{:pane} option in Figure
845     \ref{fig-color-editor} uses all three kinds of panes provided by
846     \CLIM{}. It uses two application-panes to display colors, two layout
847     panes (\class{vbox-pane} and \class{hbox-pane}) and three gadget panes
848     (\class{slider-pane}).
849    
850     In contrast to \class{hello-world}, we do not need a specialized pane
851     class here. We can use an application-pane for displaying chosen
852     colors. An application pane supports graphics operations and invokes
853     generic functions on the pane when input events are received. For the
854     color editor, we only need its ability to refresh its background
855     color.
856    
857     The \macro{vertically} and \macro{horizontally} convenience macros
858     provide an interface to the \class{hbox-pane} and \class{vbox-pane}
859     classes. Most \CLIM{} layout panes provide similar convenience
860     macros. The vertical box pane arranges its children in a stack from
861     top to bottom in the order they are listed at creation in the
862     vertically form. This pane type also supports inter-element space and
863     ``pieces of glue'' at arbitrary points in the children sequence. In
864     the color editor frame, the \constant{+fill+} ``glue'' is used to
865     absorb all extra space when too much vertical space is allocated to
866     the vertical box. \CLIM{} also provides a horizontal box which does
867     the same thing except in the horizontal direction.
868    
869     In the \macro{horizontally} macro in
870     \figurename~\ref{fig-color-editor}, we do not supply forms to be
871     evaluated directly. Instead, \method{horizontally} processes a form
872     wrapped up in a list. The first list element is a rational number
873     which denotes the amount of space the pane generated by the following
874     form is allowed to occupy in the resulting horizontal layout. In our
875     code in \figurename~\ref{fig-color-editor}, \class{hbox-pane}
876     generated from the \macro{horizontally} macro has a space requirement
877     on its own. The whole composite pane is forced to have a size 200
878     pixels high.
879    
880     Now we are ready to turn to the gadget panes. The color editor uses
881     three sliders one for each component of RGB.
882     \method{make-color-slider} creates all three sliders that differ by
883     \variable{id}, \variable{initval} and \variable{label}. The first two
884     variables are handed to \method{make-pane} to construct the slider
885     panes. The remaining initargs for \method{make-pane} are shared across
886     all three entities. To decorate each slider-pane with a proper label,
887     each of them is wrapped up in a \class{label-pane} via the
888     \macro{labelling} convenience macro.
889    
890     The slider gadget protocol defines two callback functions:
891     \method{drag-callback} is repeatedly invoked while the slider is being
892     dragged by the user, and \method{value-change-callback} is invoked
893     when the slider is released in a new location. Notice that this
894     specification is sufficiently abstract to allow a variety of different
895     look and feels for a slider. For example, no guarantee is made as to
896     whether the mouse button is held down during dragging, or whether the
897     mouse button is pressed once to start and again to stop dragging.
898    
899     We use the gadget id to distinguish between the red, green and blue
900     slider in the callback code. We could use three different callback
901     functions here, but such callbacks would have much more similarities
902     than differences, thus we do not do that here. Instead, we distinguish
903     the gadget by their \variable{id}.
904    
905     The \method{drag-callback} method resets the background of
906     \variable{drag-feedback-pane} and delegates its redrawing to
907     \method{redisplay-frame-pane}, while \method{value-change-callback}
908     does the same for the frame's current color pane. These methods use
909     the \variable{id} argument of the gadget to determine which color
910     component was changed.
911    
912     The color editor frame uses the \keyword{:menu-bar} option to indicate
913     that a menu-bar should be added to the application frame. Frame
914     commands defined with \code{:menu t} are accessible from the
915     menu-bar. In this example, we define only one command named
916     \code{com-quit} which is presented as ``Quit'' to the
917     user. \code{com-quit} is defined via
918     \macro{define-color-editor-command}. This macro is generated
919     automatically along \macro{define-application-frame} from the
920     application frame's name. \code{com-quit} simply closes the
921     application frame causing the termination of the frame's
922     top-level-loop. In the next example, commands will be explored in
923     greater detail.
924    
925     \begin{figure*}[t] \lstset{style=framestyle}
926     \lstinputlisting{draw-frame-def-app}
927     \caption{define-application-frame for
928     \class{draw-frame}}\label{fig-draw-defapp}\label{fig-draw-handlerepaint}
929     \end{figure*}
930    
931     We can invoke the color-editor with the regular
932     \method{run-top-level-frame}/\method{make-application-frame}
933     combination.
934     \lstset{style=inlinestyle}
935     \begin{lstlisting}
936     (run-top-level-frame
937     (make-application-frame 'color-edit))
938     \end{lstlisting}
939    
940    
941     \subsection{A simple drawing application}
942    
943     Next in our show case, we have a simple drawing application that draws
944     lines and inserts text interactively. Our simple drawing program
945     defines commands for various drawing operations and binds specific
946     input events to these commands.
947    
948     The application frame is defined in
949     \figurename~\ref{fig-draw-defapp}. A different approach is used to
950     generate the pane hierarchy. Instead of mixing the layout and pane
951     information, we used the \keyword{:panes} keyword to list all panes
952     that should be available in frame layouts. The \keyword{:layouts}
953     keyword combines them into several layouts. It is possible to define
954     multiple layouts with this option. We define two simple layouts,
955     \code{default-layout} and \code{alternative}.
956    
957     \begin{figure*}[t]
958     \lstset{style=framestyle}
959     \lstinputlisting{draw-frame-commands}
960     \caption{Commands for \class{draw-frame}}\label{fig-draw-commands}
961     \end{figure*}
962    
963     \begin{figure*}
964     \lstset{style=framestyle}
965     \lstinputlisting{draw-frame-interfacing}
966     \caption{User Interfaces}\label{fig-draw-interfacing}
967     \end{figure*}
968    
969     There are two options to \macro{define-application-frame} that we have
970     not seen before, \keyword{:command-definer} and \keyword{:top-level}
971     (both with there defaults). \keyword{:command-definer} is used to
972     specify a name for a command-defining macro for this frame
973     class. Passing \constant{t} to this option (its default) generates a
974     command definer named
975     \macro{define-\texttt{<}frame-name\texttt{>}-command}. We can use the
976     command-defining macro as convenience macro for
977     \method{define-command} which is used to define frame commands. We
978     will see them in action before long. \keyword{:top-level} specifies a
979     special form that is used as top level command loop. The top level is
980     responsible for dequeuing and executing commands that have been
981     invoked by the user. This loop is to a application frame what the REPL
982     is to a terminal.
983    
984     This is the first example that does not use \class{clim-stream-pane}
985     (or one of its descendant) as pane class.\footnote{When using McCLIM,
986     we have to do this as there are bugs in the behavior of
987     \class{clim-stream-pane} that have not been fixed yet.} Instead, we
988     compose our own drawing pane using
989     \class{standard-extended-input-stream}, \class{basic-pane} and
990     \class{permanent-medium-sheet-output-mixin}. The first class is used
991     to provide the application programmer with stream properties for the
992     draw-pane that are required for the convenience macro
993     \macro{tracking-pointer}. \class{basic-pane} is responsible for
994     handling all requests belonging to the sheet and pane protocols in a
995     standard manner. The last class is a mixin to tag the pane as
996     permanently visible on screen during its instances' lifetime. Most
997     static user interfaces use this mixin. Notice that McCLIM is sensible
998     to the order of the superclasses.\footnote{All stream class like
999     \class{standard-extended-input-stream} must be listed before
1000     \class{basic-pane}. Otherwise, there is no stream handling facilities
1001     available.}
1002    
1003     For \class{draw-pane}, the \method{handle-repaint} method shown in
1004     \figurename~\ref{fig-draw-handlerepaint} is straight forward. It
1005     delegates background filling to the next less specific method and then
1006     iterates through the lines and strings painting them. Here, we
1007     implicitly defined the format of the \code{lines} slot and the
1008     \code{strings} slot of the application frame class. The elements of
1009     the list stored in \code{lines} are pairs of points, namely the start
1010     and end point for a line. In \code{strings}, we store the text's
1011     position as the first element of a cons and the text as its cdr.
1012    
1013     % \class{draw-frame} uses two options in
1014     % \macro{define-application-frame} that we have not encountered
1015     % before. The \keyword{:command-definer} option is used to specify a
1016     % name for a command-defining macro for this frame class. Passing
1017     % \constant{t} to this option, as in the example, indicates that a
1018     % name of the form
1019     % \macro{define-\texttt{<}frame-name\texttt{>}-command} should be
1020     % used. The command-defining macro can then be used to define commands
1021     % that are specialized to the defined frame class.
1022    
1023    
1024     Figure \ref{fig-draw-commands} shows the command definitions. We have
1025     commands for adding a text string, for adding a line and resetting the
1026     draw pane. After every command, we update the drawing pane via the
1027     auxiliary method \method{update-draw-pane}.\footnote{An experienced
1028     \CLIM{} programmer would define a display-function for
1029     \class{draw-pane}. These function is run whenever a command was
1030     executed causing the display pane to be updated with any changes. But
1031     we will save this technique for later examples.}
1032    
1033     At this point, we can actually use the application; although not very
1034     conveniently. The interactor pane can be used to invoke one of three
1035     commands, either by typing the complete command including all its
1036     parameters or by typing only the command name, then a dialog queries
1037     the user for the missing command argument. Clicking on the menu bar
1038     entries is also possible. Also in this case, the user is queried for
1039     the missing arguments.
1040    
1041     But drawing by typing coordinates is not convenient. Therefore, we
1042     attach these commands to other user interactions. Figure
1043     \ref{fig-draw-interfacing} defines input methods for pointer button
1044     presses as well as key presses on the draw pane. Both handlers invoke
1045     the respective tracking function that uses \macro{tracking-pointer} to
1046     bypass the regular input distribution channels and to dispatch events
1047     to user defined handlers.
1048    
1049     For \class{pointer-button-press-event}, the input loop manages a
1050     ``rubber-banding'' line. The \keyword{:pointer-motion} is invoked
1051     whenever the mouse pointer is moved by the user. The code attached to
1052     \keyword{:pointer-motion} clears line already drawn and draws a new
1053     line with the new pointer position. It can easily undraw the old line
1054     by the using the special ink \constant{+flipping-ink+}. When the user
1055     confirms the line by releasing the pointer button, a command to the
1056     application is synthesized via \method{execute-frame-command}
1057     supplying all required parameters.
1058    
1059     Similarly, we provide such an input facility for text input. Whenever
1060     the user hits a key in the draw-pane, the respective
1061     \method{handle-event} calls \method{track-text-drawing} which attaches
1062     the character entered to the mouse pointer. Similarly to the
1063     rubber-banding line, the user can move the around this character while
1064     he is free to append additional string characters by additional key
1065     presses. He can confirm the text position with a mouse click causing a
1066     command to be dispatched to the application frame adding the text to
1067     the application frame permanently.
1068    
1069     As each of these methods invoke \code{execute-frame-command} passing
1070     in a special command invocation form, this naturally leads to code
1071     separation of how a command is invoked (menu-bar click, click on
1072     draw-pane or typing in the interactor pane) and the code for command
1073     execution (code bodies of \method{define-command}).
1074    
1075     % \section{Shaping concepts}
1076     %
1077     % \subsection{The Extended Input Stream vs. The Event-Based Input Protocol of Sheets}
1078     %
1079     % \hrulefill
1080     %
1081     % Usually, UI toolkits are event driven from design as most windowing
1082     % systems use an event-driven design on their own. \CLIM{} supports a
1083     % different style of programming. The difference command-inversion
1084     % makes becomes mostly visible from the coding style of input
1085     % processing (performing output is rarely an asynchronus operation).
1086     %
1087     % The \CLIM{} programmer can treat the input as if they are coming
1088     % from an stream. The extendend-input-stream even provides blocking
1089     % read methods. The regular stream classes focus on character based
1090     % interaction such as \method{stream-read-char} or
1091     % \method{stream-read-line}, while the extended stream input class
1092     % provides reading of mouse clicks and keyboard presses of the pane
1093     % stream.
1094     %
1095     % Later, when we talk about presentation-type, we will present a way
1096     % to request objects with a special semantic from the user. For
1097     % instance, we require the user to provide a file pathname, or
1098     % clicking on a weekday item in a calendar. But more of
1099     % command-inversion and presentations later.
1100     %
1101     % \hrulefill
1102     %
1103     % Even when you are familar with event-based GUI programming, this
1104     % section is likely to be new to you. As said earlier, a \CLIM{}
1105     % programmer can persue a different programming style with the
1106     % extended input stream facilities. Any event-handler or command code
1107     % can query an input stream for information.
1108     %
1109     % \method{handle-event} from accept-demo shows an event handler for
1110     % pointer release events. The handler calls two stream reading
1111     % function \method{stream-read-line} and \method{stream-read-accept}.
1112     % Notice that both functions are blocking. The argument to
1113     % \method{stream-read-accept} signals that the predefined presentation
1114     % type 'pathname' is requested.
1115     %
1116     % \lstinputlisting{accept-demo-handle-event} For the second pathname
1117     % prompt, the user can either type a character-based representation of
1118     % the pathname into the query window or he can select a pathname that
1119     % is already present on screen with the pointer. accept-demo doesn't
1120     % show any pathnames, so that is only a theoretical option, but we
1121     % will see more about this option later in the presentation type demo.
1122     %
1123     % The evaluation of both format forms is block by the evaluation of
1124     % one of its argument, the stream-reading functions. Only after
1125     % further interaction with the user, the accept call returns. In many
1126     % other GUI toolkits, such a programming style is not possible as
1127     % event handlers would not be allowed to block and therefore stall the
1128     % event-handling thread.
1129     %
1130    
1131     You may notice that there are issue with redrawing with this example
1132     in McCLIM. Unfortunately, this has not been fixed before the release
1133     of this article.
1134    
1135    
1136     \section{High Level Facilities}
1137    
1138     In this section, we explain a number of higher level facilities
1139     provided by \CLIM{}, including output recording, formatted output,
1140     presentations, context sensitive input, and command
1141     processors.\footnote{Many of these facilities are derived from work
1142     done at Symbolics on the Dynamic Windows (DW) project for
1143     Genera\cite{prog-ref-manual}. See \cite{presentation-manager} for
1144     more detailed information on the motivations and design details
1145     behind DW. Many of the original contributers to DW have participated
1146     in the redesign of these facilities for \CLIM{}.} We illustrate
1147     these facilities in two examples: a directory lister and a simple
1148     schedule browser.
1149    
1150     \paragraph*{Output Recording} Many of the higher level facilities in
1151     \CLIM{} are based on the concept of output recording. The \CLIM{}
1152     output recording facility is simply a mechanism wherein a window
1153     remembers all of the output that has been performed on it. This output
1154     history (stored basically as a display list) can be used by \CLIM{}
1155     for several purposes. For example, the output history can be used to
1156     automatically support window contents refreshing (or ``damage
1157     repaint'' events). The application programmer has considerable
1158     control over the output history. Output recording can be enabled or
1159     suspended, and the history itself can be cleared or rearranged.
1160    
1161     Output records can be nested, thereby forming their own hierarchy. The
1162     leaves of this tree are typically records that represent a piece of
1163     output, say the result of a call to \method{draw-rectangle} or
1164     \method{write-string}. The intermediate nodes typically provide
1165     additional semantics to the tree, such as marking a subtree of nodes
1166     as resultant output of one particular phase of an application, for
1167     instance row and column formatting information. Chapter 16 in
1168     \cite{clim-spec} has all the details.
1169    
1170     \paragraph*{Output Formatting} \CLIM{} provides a convenient table and
1171     graph formatting facility, which is built on top of the output
1172     recording facility. The key to these formatting tools (as opposed to,
1173     say, \code{format}'s X directive) is that they dynamically compute the
1174     formatting parameters based on the actual size of the
1175     application-generated output.
1176    
1177     The application programmer uses these tools by wrapping any piece of
1178     output-producing code with advisory macros that help the system
1179     determine the structure of the output.
1180    
1181     For example, start with a simple output function that shows some
1182     information about the packages in the Lisp environment:
1183     \lstset{style=inlinestyle}
1184     \begin{lstlisting}
1185     (defun show-package-info (stream)
1186     (dolist (package (list-all-packages))
1187     (write-string (package-name package)
1188     stream)
1189     (write-string " " stream)
1190     (format stream "~D"
1191     (count-package-symbols
1192     package))
1193     (terpri stream)))
1194     \end{lstlisting}
1195     Any attempt to fix this function to produce tabular output by building
1196     in a certain fixed spacing between the package name and symbol count
1197     will either get caught by an unexpectedly long package name, or will
1198     have to reserve way to much space for the typical case. In \CLIM{}, we
1199     can use the code in Figure \ref{fig-formatting} to produce a neatly
1200     formatted table for any set of package names.
1201     \begin{figure*}
1202     \lstset{style=framestyle}
1203     \begin{lstlisting}
1204     (defun show-packages (stream)
1205     (formatting-table (stream)
1206     (dolist (package (list-all-packages))
1207     (formatting-row (stream)
1208     ;; The first column contains the package name
1209     (formatting-cell (stream)
1210     (write-string (package-name package) stream))
1211    
1212     ;; The second color contains the symbol count, aligned with the right
1213     ;; edge of the column
1214     (formatting-cell (stream :align-x ':right)
1215     (format stream "~D" (count-package-symbols-package)))))))
1216     \end{lstlisting}
1217     \caption{An output function that uses table formatting.}\label{fig-formatting}
1218     \end{figure*}
1219    
1220     % \paragraph*{Updating output} FIXME think of a GOOD example for
1221     % updating output.
1222    
1223     \paragraph*{Presentations} The next step up from preserving the mere
1224     physical appearance of output done to a window is to preserve its
1225     semantics. For example, when an application displays a Lisp pathname
1226     on the screen via \code{(format t "\~{}A" path)}, the string
1227     ``/clim/demo/cad-demo.lisp'' may appear. To the user this string has
1228     obvious semantic meaning; it is a pathname. However, to Lisp and the
1229     underlying system it is just a text string. Fortunately, in many cases
1230     the semantics can be recovered from the string. Thus the power of the
1231     various textual cut-and-paste mechanisms supported by contemporary
1232     computer systems. However, it is possible to improve upon the utility
1233     of this lowest common denominator facility (i.e. squeezing everything
1234     through its printed representation) by remembering the semantics of
1235     the output as well as its appearance. This is the idea behind
1236     presentations.
1237    
1238     A presentation is a special kind of output record that maintains the
1239     link between screen output and the Lisp data structure that it
1240     represents. A presentation remembers three things: the displayed
1241     output by capturing a subtree of output records, the Lisp object
1242     associated with the output, and the presentation type of the output.
1243     By maintaining this back pointer to the underlying Lisp data
1244     structure, the presentation facility allows output to be reused at a
1245     higher semantic level.
1246    
1247     An application can produce semantically tagged output by calling the
1248     \CLIM{} function \method{present}. For example, to display the
1249     pathname referred to above as a presentation, the application would
1250     execute:
1251     \begin{lstlisting}
1252     (present path 'pathname)
1253     \end{lstlisting}
1254     \method{present} captures the resulting output and the pathname object
1255     in a presentation of type \code{'pathname}.
1256    
1257     \paragraph*{Presentation Types} \CLIM{} defines a set of presentation
1258     types, which are arranged in a super-type/subtype lattice like the CL
1259     types. In fact, the presentation type hierarchy is an extension of the
1260     CL type hierarchy. The reason that this extended type system is needed
1261     is that the CL type system is overloaded from the UI perspective. For
1262     example, the integer 72 might represent a heart rate in one
1263     application and a Fahrenheit temperature in another, but it will
1264     always just be an integer to Lisp.
1265    
1266     The application programmer can define the UI entities of the
1267     application by defining presentation types, thus extending the
1268     presentation type library. By defining a presentation type, the
1269     programmer can centralize all of the UI aspects of the new type in one
1270     place, including output appearance and input syntax. As an example,
1271     \CLIM{} defines a pathname presentation type that defines how a
1272     pathname is displayed and how one is input. The pathname input side
1273     provides pathname completion and possibilities-display features. By
1274     defining this behavior in one place and using it in all applications
1275     that need to display or read pathnames, \CLIM{} helps build consistent
1276     user interfaces.
1277    
1278     Note that in the pathname output example given above \method{present}
1279     invokes the standard pathname displayer defined by the presentation
1280     type. However, since the presentation facility is simply based on the
1281     output recording facility, presentation semantics can be given to any
1282     output. The following example shows how the pathname object could be
1283     associated with some graphics that were displayed on the screen.
1284    
1285     \begin{lstlisting}
1286     (with-output-as-presentation
1287     (:object path
1288     :type 'pathname
1289     :stream s)
1290     (draw-rectangle* s 0 0 30 30))
1291     \end{lstlisting}
1292    
1293     \paragraph*{Context-Dependent Input} Once output is
1294     semantically-tagged, it can be reused as semantically-meaningful
1295     input. To achieve this, the application does not only have to tag its
1296     output but it also has to provide additional semantic information when
1297     doing input operations. For instance, whenever a pathname is required,
1298     the program has to use a special method in contrast to reading a
1299     string of characters.
1300    
1301     The counterpart to \method{present} is \method{accept}. It is used to
1302     establish an \concept{input context}. The input context is a
1303     presentation type that is appropriate for the current input point. For
1304     example, if the application requires the user to input a pathname, it
1305     can trigger an appropriate prompt, input parser and input context
1306     with:
1307     \begin{lstlisting}
1308     (accept 'pathname :stream s)
1309     \end{lstlisting}
1310     Typically, this invokes the input reader (or parser) that was defined
1311     for the pathname type and establishes an input context that indicates
1312     that it is waiting for a pathname.
1313    
1314     Once the input context is established, \CLIM{} automatically makes any
1315     appropriate existing output available to the user via mouse gestures.
1316     After calling \method{accept} as shown above, the user can move the
1317     mouse over any presentation that is of type pathname (or is a subtype
1318     of pathname), click on it, and the pathname object underlying the
1319     presentation is returned as the value of the call to \code{accept}.
1320    
1321     \paragraph*{Command Processors} \CLIM{} promotes the separation of
1322     command execution code and command invocation code. The command
1323     facility aids this task. Every application frame can define
1324     application commands that are accessible via various input methods.
1325     The most common are clicking on the command's entry in the menu bar or
1326     a context menu, typing the command in the interactor pane, or the
1327     application dispatches a command to itself (maybe triggered by other
1328     ways of user input or network interactions, etc.). The latter case is
1329     seen in \code{track-line-drawing} and \code{track-text-drawing} of the
1330     \class{draw-frame} example. These methods generate ``Add Line'' and
1331     ``Add String'' commands as the result of event-handling on the
1332     draw-pane.
1333    
1334     A command has a name specified as string and a set arguments specified
1335     as presentation types. Looking back at the command ``Add String'' of
1336     draw-frame, we see that this command takes a string and two integer as
1337     arguments. This type information is useful for partial command
1338     parsing. Assume the user clicks on a menu entry or types only the
1339     command name in the interactor. \CLIM{} notices that there are
1340     arguments missing in the command and requests the missing ones in a
1341     dialog via calls to \code{accept}. Mentioned early, \code{accept}
1342     establishes an input context and so the user is able to fill the
1343     missing argument with clicks on appropriate visible output objects.
1344     Also keyboard users will find semantically-tagged input methods
1345     convenient as implementations of presentation types can provide the
1346     user with a completion facility.
1347    
1348     In addition, the command processor is extensible by application
1349     programmers. For example, the command processor can be extended to
1350     support a ``noun then verb'' interaction style, where the user can
1351     first click on a displayed presentation and then invoke a command that
1352     is defined to take an argument of the selected presentation type.
1353    
1354     \subsection{A Directory Browser}
1355     \begin{figure*}
1356     \lstset{style=framestyle}
1357     \lstinputlisting{file-browser-all}
1358     \caption{File Browser}\label{fig-file-browser}
1359     \end{figure*}
1360    
1361     The \class{dirlist-frame} application is a very simple-minded file
1362     system browser using presentation types. It defines two panes, an
1363     output pane to display directory contents and an input pane to handle
1364     user typein. For the output pane, the application defines a display
1365     function. \code{dirlist-display-files} works in conjunction with the
1366     top level command loop. Per default, the command loop calls all
1367     display functions after a command was processed to make all changes in
1368     the application's data structures visible that the command execution
1369     might have caused. When all display functions have updated their
1370     panes, the command loop displays a prompt in the
1371     interactor\footnote{Might be omitted when there is no interactor pane}
1372     and waits for the next command.
1373    
1374     The \method{dirlist-display-files} display function iterates over the
1375     contents of the current directory displaying the files one by one.
1376     Each output line is produced by a call to \method{present}.
1377     \method{present} creates the association between the text lines on the
1378     screen and the Lisp pathname objects.
1379    
1380     \class{draw-frame} has a single command ``Edit directory''. The
1381     command's body interprets the pathname that it receives as a
1382     directory, obtaining a list of the files contained therein. The
1383     command simply updates the application variable
1384     \variable{active-files} with the new list.
1385    
1386     The \CLIM{} presentation substrate supports a general concept of
1387     presentation type translation. This translation mechanism can be used
1388     to map objects of one type into a different presentation type, if
1389     appropriate. For example, it might be possible to satisfy an input
1390     request for a pathname by selecting a computer user's login ID and
1391     returning the pathname of the user's home directory. This would be
1392     accomplished by defining a translator from a user-id presentation type
1393     to the pathname type. The translator would consult the system's user
1394     database to retrieve the home directory information to achieve its
1395     conversion task.
1396    
1397     The command loop of an application frame is regularly requesting
1398     commands for processing and it uses \method{accept} for its request.
1399     Hence, an input context for reading an object with the presentation
1400     type \class{command} is established and all objects that can be used
1401     as commands will become clickable on screen. Here, we can define a
1402     presentation-to-command translator that translates a pathname into the
1403     edit directory command.
1404    
1405     The presentation-to-command translator in
1406     \figurename~\ref{fig-file-browser} is very simple. It has the name
1407     \class{pathname-to-edit-command} and converts the presentation type
1408     \code{pathname} to the command \code{com-edit-directory} for the
1409     command table of \class{file-browser}. The gesture option specifies
1410     that it works with the select gesture, while the string supplied to
1411     \keyword{:documentation} is used in the context menu.
1412    
1413     This command translator has little work to do. The body of the
1414     translator has to return a list of arguments that are handed to the
1415     command \code{com-edit-directory}. But we do not need to any
1416     conversion of the supplied object, as it is already a pathname. Thus,
1417     the received object is wrapped in a list and handed back to the caller
1418     which will call \code{com-edit-directory} with the supplied objects.
1419    
1420     A simple trick is used to dispatch an initial command to the
1421     application frame. An after-method is provided for
1422     \method{adopt-frame} which runs after the frame manager has adopted
1423     the frame for displaying. This is different for an after-method on
1424     \method{initialize-instance} as an after-method on
1425     \method{adopt-frame} runs later, when the application frame instance
1426     has already a command queue associated with it.
1427    
1428     Since this application was defined with an interactor pane for user
1429     input, the user can invoke the sole command by typing its name, ``Edit
1430     Directory.'' Here, \CLIM{} supports for automatic command completion
1431     becomes visible. Only the first letter has to be typed followed by the
1432     complete action (usually Tab) and the command completion facility will
1433     complete the input to ``Edit Directory''. At this point, the \CLIM{}
1434     command loop will begin reading the arguments for that command, and
1435     will automatically enter a pathname input context. Thus, the user can
1436     fill in the required argument either by typing a pathname, or by
1437     clicking on one of the pathnames visible in the display pane.
1438    
1439     \subsection{Schedule Example}
1440    
1441     In this example, we build a simple appointment browser. Since the user
1442     of this application will frequently be dealing with the days of the
1443     week, we start by defining a new presentation type weekday. This
1444     simple presentation type, shown in Figure \ref{fig-scheduler1},
1445     represents a day of the week as a number from 0 to 6. Each day number
1446     is associated with an abbreviated day name, ``Mon,'' ``Tue,'' etc.
1447    
1448     \begin{figure*}
1449     \lstset{style=framestyle}
1450     \lstinputlisting{scheduler-part1}
1451     \caption{Scheduler: application frame, presentation type and commands}\label{fig-scheduler1}
1452     \end{figure*}
1453     \begin{figure*}
1454     \lstset{style=framestyle}
1455     \lstinputlisting{scheduler-part2}
1456     \caption{Scheduler: display functions}\label{fig-scheduler2}
1457     \end{figure*}
1458    
1459     The weekday presentation type defines two basic pieces of behavior:
1460     how a weekday is displayed, and how it is read as input. The macro
1461     \macro{define-presentation-method} is intended for specializing
1462     methods on presentation types. Via this macro, we define a printer
1463     and a parser function for the type \code{weekday}. As is the case with
1464     most presentation types, the printer and parser are duals. That is,
1465     the printer, when given an object to print, produces output that the
1466     parser can interpret to arrive back at the original object. Not in
1467     every case the parser in \code{accept} is needed to return an object
1468     of the requested type, and for simplicity the programmer might choose
1469     not to provide a parser at all.
1470    
1471     We took the easy way out with our parser. \CLIM{} provides a
1472     completion facility and instead of reading the day name of the stream
1473     and parsing it into an integer, we provided an exhaustive set of input
1474     to object mappings. The \macro{completing-from-suggestions} macro
1475     collects all suggestions made by the parser via
1476     \code{suggest}. \code{suggest} is takes an input and object as
1477     suggestion. In our case, day name taken from \variable{*days*} is the
1478     input and the number of the week \variable{i} is the object. \CLIM{}
1479     will match the input given by the user with the suggestions and in
1480     case of a match will return the corresponding object to the caller.
1481    
1482     We define an application frame for the appointment browser in Figure
1483     \ref{fig-scheduler1}. The frame defines state variables to hold the
1484     list of appointments and the current day. This information is kept in
1485     slots on the frame, so that multiple copies of the application can be
1486     run, each with its own appointment list. The application represents
1487     the appointment data as an alist containing an entry for each day of
1488     the week, with each entry containing a list of the appointments for
1489     the day. Test data is provided as a default initform.
1490    
1491     Just as in the previous example, the appointment application defines
1492     two panes, an interactor and an output display pane. The appointment
1493     application defines two commands. The ``Show Summary'' command resets
1494     the display back to the weekly summary mode by setting the
1495     \variable{current-day} slot to \constant{nil}. The ``Select Day''
1496     command sets \variable{current-day} to the value of an argument that
1497     is specified to be a weekday. This presentation type specification
1498     allows the command processor to make all presented weekday active when
1499     it is filling in this argument, as well as, provide completion
1500     assistance to the user.
1501    
1502     The command ``Select Day'' has the following argument specification:
1503     \begin{lstlisting}
1504     ((day 'weekday :gesture :select))
1505     \end{lstlisting}
1506     It takes an argument \code{day} of type \class{weekday}. Up until now,
1507     our command arguments have looked similarly to specialized lambda
1508     lists, but next to the type information the arguments of commands are
1509     also allowed to have various keyword-value pairs for selection further
1510     options. In this case, we supplied the value \code{:select} for the
1511     option \keyword{:gesture}. The macro \macro{define-command} parses
1512     this keyword-value pair and generate a presentation translator. More
1513     precisely, a presentation-to-command translator is defined that is
1514     equal in functionality to the one we have seen in the file-browser
1515     example. Whenever a presentation of the type \code{pathname} is
1516     selected (e.g. with pointer clicks) in a \class{command} input
1517     context, it is translated into a command invocation of ``Select
1518     Weekday''.
1519    
1520     Finally, we turn to the display the appointment information. The
1521     display function, \method{display-appointments}, shown in Figure
1522     \ref{fig-scheduler2}, is somewhat more complex than our earlier
1523     example. It can display two different sets of information: a weekly
1524     summary showing the days of the week and the number of appointments
1525     for each day, or a detailed description of one day's appointments.
1526    
1527     \method{display-appointments} decides which set of information to
1528     display by examining the application state variable
1529     \variable{current-day}. The table formatting facility is used to
1530     present the weekly summary information neatly organized. The daily
1531     appointment list, by contrast, is displayed using
1532     \method{write-string}. Note, however, that whenever a day of the week
1533     is displayed, it is done with a call to \code{present} using the
1534     weekday presentation type. This allows the printed weekdays to be
1535     selected either as a command or as a weekday argument. This example
1536     illustrates how an application with interesting UI behavior can be
1537     constructed from a high-level specification of its functionality.
1538    
1539     % \section{The benefits of the extended output stream}
1540     %
1541     % At the first glance, the extended output stream facilities does not
1542     % look more exciting than the output capabilities of sheets. In fact,
1543     % the output streams use the output facility of sheets to do their
1544     % job, thus the variaty of graphic operations is less or equal to that
1545     % of the lower facility. But an output stream helps to organize output
1546     % can do many things, we are not able to achieve that easy with the
1547     % low-level output tools.
1548     %
1549     % Output Recording, Table/Graph Formatting,and Incremental Redisplay
1550     % are tools that are built on top of the stream characteristic in the
1551     % extended output stream. We have already seen Table Formatting at
1552     % work in the scheduler example.
1553     %
1554     % \begin{figure*}
1555     % \hrulefill
1556     % \begin{lstlisting}
1557     % (let (a-string
1558     % sum-of-ints
1559     % (input-stream (frame-standard-input *application-frame*)))
1560     % (accepting-values (input-stream :own-window t)
1561     % (setq a-string (accept 'string :prompt "1st string" :stream input-stream))
1562     % (terpri input-stream)
1563     % (setq sum-of-ints
1564     % (+ (prog1 (or (accept 'integer :prompt "1st integer" :stream input-stream) 0)
1565     % (terpri input-stream))
1566     % (prog1 (or (accept 'integer :prompt "2nd integer" :stream input-stream) 0)
1567     % (terpri input-stream))))))
1568     % \end{lstlisting}
1569     % \hrulefill
1570     % \caption{Hairy example of accepting-values demonstrating the use of the blocking \method{accept} method}\label{accepting-values-example}
1571     % \end{figure*}
1572     %
1573     % With the \macro{accepting-values} even more is possible.
1574     % \figurename~\ref{accepting-values-example} demonstrates that it is
1575     % possible to build up a whole dialog window simply by requesting a
1576     % series of input types. It does that via \method{accepting-values}
1577     % which brings up a seperate dialog window to request a string and two
1578     % integers from the user.
1579     %
1580     % The trick of \method{accepting-value} is dual-evaluation. Its body
1581     % is evaluated twice. First to collect all accept calls and build up a
1582     % dialog. The second evaluation happens after the user has entered all
1583     % requested information and has hit the ``Ok'' button as confirmation.
1584     % In the second evaluation the entered values are returned from the
1585     % corresponding accept forms. Notice that we have to wrap
1586     % \method{accept} in an or statement for \method{+}, because when the
1587     % body is evaluated for the first time all \method{accept} forms
1588     % return \constant{nil} causing an exception if handed to
1589     % +.\footnote{In pratice, we would sum up the integers after
1590     % accepting-values, because this is much more easy to read later.}
1591     % Please do not try to mimic the code shown in
1592     % \figurename~\ref{accepting-values-example}. Nonetheless it is shown
1593     % to give the reader an insight how this sudden violation of
1594     % evaluation sequence is implemented.
1595     %
1596     % We should emphasize that only the body of accepting-values is
1597     % evaluated twice. The \method{let} statement in
1598     % \figurename~\ref{accepting-values-example} does not return before
1599     % \method{accepting-values} does. This is not a form of continuation.
1600     % \method{accepting-values} effectively blocks the event thread just
1601     % as a single \method{accept} would (\method{accepting-values} can
1602     % therefore be seen as something that aggregates several accept
1603     % statements). Despite this blocking, \CLIM{} manages to continue
1604     % event handling.
1605    
1606     \section{Conclusion}
1607    
1608     The series of examples presented in this article illustrate the broad
1609     range of functionality provided by \CLIM{}. The later examples,
1610     especially, demonstrate that complex user interfaces can be built
1611     economically and modularly using \CLIM{}. Many of the higher level
1612     facilities make it possible to separate the issues involved in
1613     designing an application's user interface from the functionality of
1614     the application.
1615    
1616     On the other hand, many of these higher level facilities may not be
1617     appropriate for all users. \CLIM{}'s lower level facilities and clean
1618     modularization of the higher level facilities provide these users with
1619     portable platform and a framework for implementing their own user
1620     interface toolkits and frameworks. In addition, \CLIM{}'s use of CLOS
1621     to define explicit, documented protocols provides application
1622     programmers with the opportunity to customize \CLIM{} and support
1623     interfaces not anticipated by the \CLIM{} designers.
1624    
1625     A free \CLIM{} implementation is available as McCLIM. McCLIM only
1626     works on X windows at the moment. An experimental port to Mac OS X
1627     called Beagle is in progress. It can be found on
1628     http://common-lisp.net/project/mcclim/.
1629    
1630     \section*{Acknowledgments}
1631    
1632     \paragraph*{Original article} \CLIM{} represents the cooperative
1633     effort of individuals at several companies. These individuals include
1634     Jim Veitch, John Irwin, and Chris Richardson of Franz; Richard Lamson,
1635     David Linden, and Mark Son-Bell of ILA; Paul Wieneke and Zack Smith of
1636     Lucid; Scott McKay, John Aspinall, Dave Moon and Charlie Hornig of
1637     Symbolics; and Gregor Kizcales and John Seely Brown of Xerox PARC.
1638     Mark Son-Bell and Jon L. White have help us improve this paper.
1639    
1640     \paragraph*{2006 update} Clemens Fruhwirth thanks the developers for
1641     McCLIM for producing a free \CLIM{} implementation, and especially
1642     Robert Strandh for answering so many questions in conjunction with
1643     McCLIM.
1644    
1645     \bibliographystyle{alpha}
1646     \bibliography{guided-tour}
1647    
1648     \end{document}

  ViewVC Help
Powered by ViewVC 1.1.5