Almost all of the changes in the following are simple tweaks to fix grammatical nits. However, there were a few places where I inserted comments (invisible to the reader of the formatted documents) suggesting amplifications that I didn't feel qualified to write myself. For example, there is a very helpful discussion about the notion of protocol that is found in a footnote; I think that this should be pulled out of the footnote and moved to the introduction, because it helps the reader understand the whole discussion. Such comments are marked with a date stamp with my initials.
I only managed to get up to the end of section 4 (before the start of "Simple Applications." I'll try to do more as time permits.
Unless I hear a squawk pretty soon (24 hours?), I'll commit the changes. They're really pretty minor.
Index: guided-tour.tex =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Doc/Guided-Tour/guided-tour.tex,v retrieving revision 1.2 diff -c -r1.2 guided-tour.tex *** guided-tour.tex 9 Feb 2006 13:20:38 -0000 1.2 --- guided-tour.tex 14 Mar 2006 19:41:16 -0000 *************** *** 89,98 **** The Common Lisp Interface Manager addresses this problem by specifying an interface to a broad range of services necessary or useful for developing graphical user interfaces. These services include low level ! facilities like geometry, graphics, event-oriented input, and ! windowing; intermediate level facilities like support for Common Lisp stream operations, output recording, and advanced output formatting; ! and high level facilities like context sensitive input, an adaptive toolkit, and an application building framework.
\CLIM{} implementations will eventually support a large number of window environments --- 89,98 ---- The Common Lisp Interface Manager addresses this problem by specifying an interface to a broad range of services necessary or useful for developing graphical user interfaces. These services include low level ! facilities such as geometry, graphics, event-oriented input, and ! windowing; intermediate level facilities such as support for Common Lisp stream operations, output recording, and advanced output formatting; ! and high level facilities such as context sensitive input, an adaptive toolkit, and an application building framework.
\CLIM{} implementations will eventually support a large number of window environments *************** *** 101,110 **** to the degree that it makes sense. For example, \CLIM{} top level windows are typically mapped onto host windows, and input and output operations are ultimately performed by host window system ! code. Another example is that \CLIM{} supports the incorporation of toolkits written in other languages. A uniform interface provided by \CLIM{} allows Lisp application programmers to deal only with Lisp ! objects and functions regardless of their operating platform.
An important goal that has guided the design of \CLIM{} was to layer the specification into a number of distinct --- 101,110 ---- to the degree that it makes sense. For example, \CLIM{} top level windows are typically mapped onto host windows, and input and output operations are ultimately performed by host window system ! code. \CLIM{} supports the incorporation of toolkits written in other languages. A uniform interface provided by \CLIM{} allows Lisp application programmers to deal only with Lisp ! objects and functions regardless of the operating platform.
An important goal that has guided the design of \CLIM{} was to layer the specification into a number of distinct *************** *** 127,136 ****
For example, \CLIM{}'s application framework and adaptive toolkit allow programmers to develop applications that automatically adopt the look ! and feel of the host's environment. (We often call this ``adaptiveness,'' ``look and feel independence,'' or occasionally more ! picturesquely, ``chameleon look and feel''.) However, many users may ! need or want to define a particular look and feel that stays constant across all host environments (we call this ``portable look and feel''). Such users can circumvent the look and feel adaptiveness provided by \CLIM{}, while still using most of the application --- 127,136 ----
For example, \CLIM{}'s application framework and adaptive toolkit allow programmers to develop applications that automatically adopt the look ! and feel of the host's environment. We often call this ``adaptiveness,'' ``look and feel independence,'' or occasionally more ! picturesquely, ``chameleon look and feel''. However, many users may ! need or want to define a particular look and feel that is constant across all host environments (we call this ``portable look and feel''). Such users can circumvent the look and feel adaptiveness provided by \CLIM{}, while still using most of the application *************** *** 168,174 **** \caption{An Overview of \CLIM{} facilities}\label{clim-facilities} \end{figure*}
! \paragraph*{Graphic substrate} \CLIM{} provides a portable interface to a broad set of graphics functions for drawing complex geometric shapes.
--- 168,174 ---- \caption{An Overview of \CLIM{} facilities}\label{clim-facilities} \end{figure*}
! \paragraph*{Graphics substrate} \CLIM{} provides a portable interface to a broad set of graphics functions for drawing complex geometric shapes.
*************** *** 177,183 ****
\paragraph*{Extended Streams} \CLIM{} integrates the Common Lisp Stream I/O functionality with the \CLIM{} graphics, windowing, and ! panes facilities. Next to ordinary text, the programmer can send a button, a picture or any other arbitrary widget to a \CLIM{} output stream and \CLIM{} will display the widget in the sheet associated with the output stream. --- 177,185 ----
\paragraph*{Extended Streams} \CLIM{} integrates the Common Lisp Stream I/O functionality with the \CLIM{} graphics, windowing, and ! panes facilities. ! % I believe that this was what was intended [2006/03/14:rpg] ! In addition to ordinary text, the programmer can send a button, a picture or any other arbitrary widget to a \CLIM{} output stream and \CLIM{} will display the widget in the sheet associated with the output stream. *************** *** 189,202 **** \paragraph*{Formatted Output} \CLIM{} provides a set of high-level macros that enable programs to produce neatly formatted tabular and graphical displays easily.\footnote{This also includes Graph ! Formatting.}
\paragraph*{Presentations} \CLIM{} provides the ability to associate semantics with output, such that Lisp objects may be retrieved later via user gestures (e.g.{} mouse clicks) on their displayed representation. This context sensitive input is modularly layered on top of the output recording facility and is integrated with the Common ! Lisp type system. A mechanism for type coercion is also included, providing the basis for powerful user interfaces.
\paragraph*{Panes} \CLIM{} provides \concept{panes} that are analogous --- 191,209 ---- \paragraph*{Formatted Output} \CLIM{} provides a set of high-level macros that enable programs to produce neatly formatted tabular and graphical displays easily.\footnote{This also includes Graph ! Formatting. Graph formatting is only partly implemented in McCLIM ! at this date (March 2006).}
\paragraph*{Presentations} \CLIM{} provides the ability to associate semantics with output, such that Lisp objects may be retrieved later via user gestures (e.g.{} mouse clicks) on their displayed representation. This context sensitive input is modularly layered on top of the output recording facility and is integrated with the Common ! Lisp type system. ! % I understand this, but I suspect it's not going to be obvious to the ! % ordinary reader why type coercion provides the basis for a user ! % interface... [2006/03/14:rpg] ! A mechanism for type coercion is also included, providing the basis for powerful user interfaces.
\paragraph*{Panes} \CLIM{} provides \concept{panes} that are analogous *************** *** 212,220 **** independence by specifying a set of abstract gadget pane protocols. These protocols define a gadget in terms of its function and not in terms of the details of its appearance or ! operation. Application that use these gadget types and related facilities will automatically adapt to use whatever toolkit is ! available and appropriate for the host environment. In addition, portable Lisp-based implementations of the abstract gadget pane protocols are provided.\footnote{\mcclim{} does not support look and feel adaptiveness at the moment except for the experimental beagle backend for Mac --- 219,227 ---- independence by specifying a set of abstract gadget pane protocols. These protocols define a gadget in terms of its function and not in terms of the details of its appearance or ! operation. Applications that use these gadget types and related facilities will automatically adapt to use whatever toolkit is ! available on and appropriate for the host environment. In addition, portable Lisp-based implementations of the abstract gadget pane protocols are provided.\footnote{\mcclim{} does not support look and feel adaptiveness at the moment except for the experimental beagle backend for Mac *************** *** 234,240 **** presentation. Commands can also be invoked explicitly by the programmer.
! \paragraph*{Dialogs and Incremental Update} Incremental Redisplay goes a bit further than Output Recording. With Incremental Redisplay, an output record can not only reproduce content that was written to a stream, the \CLIM{} programmer can also attach the code that generated --- 241,249 ---- presentation. Commands can also be invoked explicitly by the programmer.
! % added ``Redisplay'' below so that the paragraph header harmonizes ! % with the jargon used in the paragraph. ! \paragraph*{Dialogs and Incremental Update/Redisplay} Incremental Redisplay goes a bit further than Output Recording. With Incremental Redisplay, an output record can not only reproduce content that was written to a stream, the \CLIM{} programmer can also attach the code that generated *************** *** 253,262 ****
\section{Our first application}
! We will spend a few lines of code for the trivial Hello World example to give the reader a test case to verify his \CLIM{} setup. It also serves as a point of reference from where the reader can start his ! explorations for more challenging \CLIM{} facilities. We do not try to elaborate the \CLIM{} concepts in detail here, but simply use them with a brief discussion. The confused reader may hope for a more in-depth explanation in the following section. Please regard --- 262,271 ----
\section{Our first application}
! We will start with a few lines of code for the trivial Hello World example to give the reader a test case to verify his \CLIM{} setup. It also serves as a point of reference from where the reader can start his ! explorations of more challenging \CLIM{} facilities. We do not try to elaborate the \CLIM{} concepts in detail here, but simply use them with a brief discussion. The confused reader may hope for a more in-depth explanation in the following section. Please regard *************** *** 264,290 **** \concept{sheet hierarchy}, \concept{graft} and \concept{top-level loop} as terms we will discuss later.
! Also, we conduct excessive \CLIM{} specification referencing in footnotes. The motivation for this is to show that all the relevant information can be found in the \CLIM{} 2 specification\cite{clim-spec}. Before a good \CLIM{} programmer can master any \CLIM{} concept, he has to get used to the style of writing ! of the specification first as this is the most relevant work for ! \CLIM{}. The best we can do in this context is to provide pointers and references and hope that the interested reader starts to explore the surrounding text sections on his own.
After loading a \CLIM{} implementation, the package \keyword{:clim-user} is available to absorb user code. This package is ! a good start for experimentations and first steps. When proper packaging is required, simply include the packages \keyword{:clim} and ! \keyword{:clim-lisp} in your \keyword{:use} list.
The central element of \CLIM{} application programming is the \concept{application-frame}. An application frame is defined via \code{define-application-frame}.\footnote{See Section 28.2 ``Defining ! and Creating Application Frames'' in \cite{clim-spec}.} Here comes ! the application frame for Hello World: \lstset{style=inlinestyle} \lstinputlisting{hello-world-def-app}
--- 273,299 ---- \concept{sheet hierarchy}, \concept{graft} and \concept{top-level loop} as terms we will discuss later.
! We provide extensive \CLIM{} specification references in footnotes. The motivation for this is to show that all the relevant information can be found in the \CLIM{} 2 specification\cite{clim-spec}. Before a good \CLIM{} programmer can master any \CLIM{} concept, he has to get used to the style of writing ! of the specification, as this is the most relevant work for ! \CLIM{}. The best we can do in this short paper is provide pointers and references and hope that the interested reader starts to explore the surrounding text sections on his own.
After loading a \CLIM{} implementation, the package \keyword{:clim-user} is available to absorb user code. This package is ! a good start for experimentation and first steps. When proper packaging is required, simply include the packages \keyword{:clim} and ! \keyword{:clim-lisp} in your new package's \keyword{:use} list.
The central element of \CLIM{} application programming is the \concept{application-frame}. An application frame is defined via \code{define-application-frame}.\footnote{See Section 28.2 ``Defining ! and Creating Application Frames'' in \cite{clim-spec}.} Here is ! the application frame definition for Hello World: \lstset{style=inlinestyle} \lstinputlisting{hello-world-def-app}
*************** *** 293,309 **** \lstinputlisting{hello-world-handle-repaint} \caption{\method{handle-repaint} for \class{hello-world-pane}}\label{hello-world-repaint} \end{figure*} ! Its basic syntax is similar to \code{defclass} because \code{define-application-frame} also generates classes. In this case, it creates a frame class \class{hello-world} that has no superclass ! except \class{frame} which is added automatically.
With \code{:pane}, we define a \concept{top-level-pane} that becomes ! the content of the fresh window that belongs to an application ! frame. But sometimes, an application frame is swallowed by another ! application and only space in an other existing window is reserved. For instance, a web site management tool might swallow a ! text editor, so the user has the option to edit web sites without switching to another application.
% \footnote{The graft is the root of a sheet hierarchy and on most --- 302,319 ---- \lstinputlisting{hello-world-handle-repaint} \caption{\method{handle-repaint} for \class{hello-world-pane}}\label{hello-world-repaint} \end{figure*} ! \code{define-application-frame}'s basic syntax is similar to \code{defclass} because \code{define-application-frame} also generates classes. In this case, it creates a frame class \class{hello-world} that has no superclass ! except \class{frame} (which is added automatically).
With \code{:pane}, we define a \concept{top-level-pane} that becomes ! the content of a fresh window that belongs to an application ! frame. Although the usual case is for an application frame to ! correspond to a top level window, sometimes an application frame is swallowed by another ! application and only space in another existing window is reserved. For instance, a web site management tool might swallow a ! text editor, so that the user has the option to edit web sites without switching to another application.
% \footnote{The graft is the root of a sheet hierarchy and on most *************** *** 320,339 **** created. We use \method{make-pane} to construct a pane as the top-level-pane for frame instances. \method{make-pane} is a constructor for panes.\footnote{See Section 29.2 ``Basic Pane ! Construction'' in \cite{clim-spec}.} We can treat it as \code{make-instance} especially made for pane classes. Let us have a look at the definition of \class{hello-world-pane}.
\lstset{style=inlinestyle} \lstinputlisting{hello-world-defclass}
The one and only superclass of \class{hello-world-pane} is ! \class{clim-stream-pane}\footnote{See Section 29.4 ``CLIM Stream ! Panes'' in \cite{clim-spec}.}. As there are no additional slots, an ! experienced \CLOS{} user might guess that we will use \class{hello-world-pane} solely for method specialization. Before doing so, let us have a look what we have actually ! inherited from \class{clim-stream-pane}\footnote{Internal classes ! removed from listing.}:
\lstset{style=inlinestyle} \begin{lstlisting} --- 330,349 ---- created. We use \method{make-pane} to construct a pane as the top-level-pane for frame instances. \method{make-pane} is a constructor for panes.\footnote{See Section 29.2 ``Basic Pane ! Construction'' in \cite{clim-spec}.} We can treat it as an analog to \code{make-instance} especially made for pane classes. Let us have a look at the definition of \class{hello-world-pane}.
\lstset{style=inlinestyle} \lstinputlisting{hello-world-defclass}
The one and only superclass of \class{hello-world-pane} is ! \class{clim-stream-pane}.\footnote{See Section 29.4 ``CLIM Stream ! Panes'' in \cite{clim-spec}.} As there are no additional slots, an ! experienced \CLOS{} programmer might guess that we will use \class{hello-world-pane} solely for method specialization. Before doing so, let us have a look what we have actually ! inherited from \class{clim-stream-pane}:\footnote{Internal classes ! removed from listing.}
\lstset{style=inlinestyle} \begin{lstlisting} *************** *** 349,354 **** --- 359,368 ---- BASIC-PANE \end{lstlisting}
+ % would it be appropriate to define the phrase ``protocol class'' + % here? I'm not sufficiently confident in my CLIM fu to provide a + % definition myself. [2006/03/14:rpg] + \class{basic-pane} is the foundation of all pane classes. It provides reasonable defaults for all protocol methods and inherits from the protocol class \class{pane}. In turn, \class{pane} inherits from *************** *** 399,404 **** --- 413,425 ----
\subsection{Geometry}
+ % The footnote describing ``protocol'' below seems to give a critical + % insight into the style and functioning of CLIM. It should certainly + % be promoted out of footnote and into body text. I'm inclined to + % think it should be promoted to the introduction. The notion of + % Protocol is alluded to there, but not clearly described. + % [2006/03/14:rpg] + To \CLIM{}, geometry means \concept{regions}. A region is either bound or unbound and has a dimensionality of either zero, one or two. That corresponds to a point, a path or an area respectively. Regions can be *************** *** 421,430 **** transformation is affine when every straight line remains straight after transformation. Transformations can be composed arbitrarily. The programmer can attach transformations to mediums and panes. In layout ! panes, \CLIM{} uses transformation to map the coordinates of children ! panes to the coordinate system of its parents. All drawing settings ! can be changed permanently, or in the context of a ! \macro{with-drawing-options} macro temporarily.
\subsection{The Windowing Substrate} --- 442,456 ---- transformation is affine when every straight line remains straight after transformation. Transformations can be composed arbitrarily. The programmer can attach transformations to mediums and panes. In layout ! panes, \CLIM{} uses transformations to map the coordinates of child ! panes to the coordinate system of their parents. ! ! % This was attached to the previous paragraph, but doesn't seem to ! % have anything to do with its topic. I'm inclined to think that this ! % could use some further expansions (have we adequately explained what ! % a drawing setting is?) [2006/03/14:rpg] ! All drawing settings can be changed either permanently, or temporarily ! in the context of the \macro{with-drawing-options} macro.
\subsection{The Windowing Substrate} *************** *** 519,525 **** specialization, so the application developer can implement special policies for selected events. For instance, when a sheet notices through a \code{window-configuration-event} that the sheet's size ! changed, it might redo its layout for its children panes.
% There are two mixins that specialize on the % \code{window-repaint-event} class as event argument to --- 545,551 ---- specialization, so the application developer can implement special policies for selected events. For instance, when a sheet notices through a \code{window-configuration-event} that the sheet's size ! has changed, it might redo its layout for its children.
% There are two mixins that specialize on the % \code{window-repaint-event} class as event argument to *************** *** 561,566 **** --- 587,598 ---- % the sheet's medium. According to the \mcclim{} authors, this is done % for optimization.}
+ % in the topic sentence here, should it read ``of sheets'' or ``of + % mediums'' (media?). I'm not sure, but if ``sheets'' is meant, we + % should probably have some transition wording here to explain how we + % got from discussing mediums above to discussing sheets here. + % [2006/03/14:rpg] + The graphic output capabilities of sheets range from simple line style and text style customization over rendering various geometrical shapes, a color model capable of doing alpha blending, composable *************** *** 569,577 **** specified briefly in Section 8.3 ``Output Protocol''and more precisely in Chapters 10-14 of \cite{clim-spec}.
! \CLIM{} lives in idealized world in terms of graphics operations. A \CLIM{} programmer can use an infinitely long and wide drawing pane ! with an arbitrarily precise resolution and continuously variable opacity. As rendering devices with these properties are rare, we need to render the idealized graphic description to a device with finite size and a fixed drawing precision. The rendering rules --- 601,609 ---- specified briefly in Section 8.3 ``Output Protocol''and more precisely in Chapters 10-14 of \cite{clim-spec}.
! \CLIM{} lives in an idealized world in terms of graphics operations. A \CLIM{} programmer can use an infinitely long and wide drawing pane ! with arbitrarily precise resolution and continuously variable opacity. As rendering devices with these properties are rare, we need to render the idealized graphic description to a device with finite size and a fixed drawing precision. The rendering rules *************** *** 602,608 **** system window hierarchy) when the frame is adopted.
To build a user interface, an application programmer defines one or ! more frames classes. These frame classes define a number of frame properties including application specific state and a hierarchy of panes (i.e.{} user interface gadgets and regions, for interacting with the users). Frame classes also provide hooks for customizing --- 634,640 ---- system window hierarchy) when the frame is adopted.
To build a user interface, an application programmer defines one or ! more frame classes. These frame classes define a number of frame properties including application specific state and a hierarchy of panes (i.e.{} user interface gadgets and regions, for interacting with the users). Frame classes also provide hooks for customizing *************** *** 615,621 **** up is usually quite different from the code that is used to generate the content of application frames. This is unusual for a windowing toolkit as most of them unify the generation of dialog content and ! content of other windows types.
\CLIM{} generates a dialog with the appropriate input gadget as consequence of a series of input requests. Thanks to the stream --- 647,653 ---- up is usually quite different from the code that is used to generate the content of application frames. This is unusual for a windowing toolkit as most of them unify the generation of dialog content and ! content of other window types.
\CLIM{} generates a dialog with the appropriate input gadget as consequence of a series of input requests. Thanks to the stream *************** *** 624,634 **** asynchronously handling confirmation or cancel button clicks. For instance, the programmer requests a string from the user and the user is presented with a prompt, an editable text field, and two buttons ! for confirmation and canceling. Only after the user hits the ! confirmation button, the string requesting function returns; the programmer can directly use the function's return value which is the ! string provided by the user. Clicking the cancel button is dealt with by throwing to an ! \code{abort} tag.
From the caller's perspective, an attempt to separate application frames and dialogs could be: a dialog window itself is side-effect --- 656,674 ---- asynchronously handling confirmation or cancel button clicks. For instance, the programmer requests a string from the user and the user is presented with a prompt, an editable text field, and two buttons ! for confirmation and canceling. ! The string requesting function returns only after the user hits the ! confirmation button. The programmer can directly use the function's return value which is the ! string provided by the user. ! % Is the following rewrite correct? Seems like in the actual code an ! % abort-gesture is signaled, but it is handled by invoking an abort, ! % if no abort-gesture handler is found. [2006/03/14:rpg] ! % OLD: ! % Clicking the cancel button is dealt with by throwing to an ! % \code{abort} tag. ! Clicking the cancel button is dealt with by signaling an abort-gesture ! condition.
From the caller's perspective, an attempt to separate application frames and dialogs could be: a dialog window itself is side-effect *************** *** 719,727 **** Panes and sheets as defined by the windowing substrate have in common that they are associated with a region on screen, a parent, and optional children. They differ in their usage of the input and output ! capabilities. A sheet is passive and intended for others to be used, ! while a pane already contains this active part. This relationship ! leads that panes are implemented as subclasses of \class{basic-sheet} augmenting the class with an active part. For instance, a button-pane actively draws its own button representation on its allotted screen area and a click on the correct button area triggers a callback for --- 759,769 ---- Panes and sheets as defined by the windowing substrate have in common that they are associated with a region on screen, a parent, and optional children. They differ in their usage of the input and output ! capabilities. A sheet is passive and intended to be used by other, ! active components, ! while a pane already contains this active part. ! For this reason, ! panes are implemented as subclasses of \class{basic-sheet} augmenting the class with an active part. For instance, a button-pane actively draws its own button representation on its allotted screen area and a click on the correct button area triggers a callback for *************** *** 745,759 **** in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can ! specify an alternative callback method for all callbacks available. By providing the \keyword{:activate-callback} initarg, the programmer can change the callback to any regular or generic function. By convention, ! all callbacks can be changed by providing an initarg keyword equal to the callback's name. See Chapter 30 in \cite{clim-spec} for a listing and description of available callbacks.
\CLIM{} also provides composite and layout panes. These pane types are ! used for aggregating several children panes into a bigger single pane that has a layout according to the requested directives. For example, \CLIM{} provides two pane classes, \class{hbox-pane} and \class{vbox-pane}, that lay out their children in horizontal rows or --- 787,802 ---- in the case where the programmer needs a lot of buttons with related behavior, creating a subclass for changing a single specific callback is not economical. Hence upon gadget creation, the programmer can ! specify an alternative callback method for any callback available. For ! example, by providing the \keyword{:activate-callback} initarg, the programmer can change the callback to any regular or generic function. By convention, ! any callback can be changed by providing an initarg keyword equal to the callback's name. See Chapter 30 in \cite{clim-spec} for a listing and description of available callbacks.
\CLIM{} also provides composite and layout panes. These pane types are ! used for aggregating several child panes into a bigger single pane that has a layout according to the requested directives. For example, \CLIM{} provides two pane classes, \class{hbox-pane} and \class{vbox-pane}, that lay out their children in horizontal rows or *************** *** 764,774 **** management via the windowing protocol. He is provided with a set of convenience macros that allows elegant interfaces composed simply by wrapping the respective pane construction code into the convenience ! macros.
Application pane classes can be used for subclassing. They can be used to present application specific data -- for instance by specializing ! \method{handle-repaint} -- and manage user interactions -- for instance by specializing \method{handle-event}.
\subsection{Commands} --- 807,817 ---- management via the windowing protocol. He is provided with a set of convenience macros that allows elegant interfaces composed simply by wrapping the respective pane construction code into the convenience ! macros. % could we name the convenience macros here? [2006/03/14:rpg]
Application pane classes can be used for subclassing. They can be used to present application specific data -- for instance by specializing ! \method{handle-repaint} -- and to manage user interactions -- for instance by specializing \method{handle-event}.
\subsection{Commands} *************** *** 784,790 **** choose to export as an explicit user entry point. A command is defined to have a name and a set of zero or more operands, or arguments. These commands can then be invoked using a variety of interaction ! techniques. For example, commands can be invoked from menu, keyboard accelerators, direct typein, mouse clicks on application data, or gadgets.
--- 827,833 ---- choose to export as an explicit user entry point. A command is defined to have a name and a set of zero or more operands, or arguments. These commands can then be invoked using a variety of interaction ! techniques. For example, commands can be invoked from menus, keyboard accelerators, direct typein, mouse clicks on application data, or gadgets.