[mcclim-cvs] CVS mcclim/Doc

[rstrandh]

Update of /project/mcclim/cvsroot/mcclim/Doc
In directory clnet:/tmp/cvs-serv27169

Modified Files:
	manual.tex 
Log Message:
Section on how CLIM is different from traditional GUI toolkits.


--- /project/mcclim/cvsroot/mcclim/Doc/manual.tex	2006/10/30 06:26:53	1.32
+++ /project/mcclim/cvsroot/mcclim/Doc/manual.tex	2006/10/30 08:21:01	1.33
@@ -95,6 +95,78 @@
 and not well described.  It will be noted here when they are partially
 implemented in McCLIM or not implemented at all.
 
+\section{How CLIM is different}
+
+Many new users of CLIM have a hard time trying to understand how it
+works and how to use it.  A large part of the problem is that many
+such users are used to more traditional GUI toolkits, and they try to
+fit CLIM into their mental model of how GUI toolkits should work. 
+
+But CLIM is much more than just a GUI toolkit, as suggested by its
+name, it is an \emph{interface manager}, i.e. it is a complete
+mediator between application ``business logic'' and the way the user
+interacts with objects of the application.  In fact, CLIM doesn't have
+to be used with graphics output at all, as it contains a large
+collection of functionality to manage text. 
+
+Traditional GUI toolkits have an \emph{event loop}.  Events are
+delivered to GUI elements called \emph{gadgets} (or \emph{widgets}),
+and the programmer attaches \emph{event handlers} to those gadgets in
+order to invoke the functionality of the application logic.  While
+this way of structuring code is sometimes presented as a virtue
+(``Event-driven programming''), it has an unfortunate side effect,
+namely that event handlers are executed in a null context, so that it
+becomes hard to even remember two consecutive events.  The effect of
+event-driven programming is that applications written that way have
+very rudimentary interaction policies.
+
+At the lowest level, CLIM also has an event loop, but most application
+programmers never have any reason to program at that level with CLIM.
+Instead, CLIM has a \emph{command loop} at a much higher level than
+the event loop.  At each iteration of the command loop:
+
+\begin{itemize}
+\item A command is acquired.  You might satisfy this demand by
+  clicking on a menu item, by typing the name of a command, by hitting
+  some kind of keystroke, by pressing a button, or by pressing some
+  visible object with a command associated with it;
+\item Arguments that are required by the command are acquired.  Each 
+    argument is often associated with a \emph{presentation type}, and
+    visible objects of the right presentation type can be clicked on
+    to satisfy this demand.  You can also type a textual
+    representation of the argument, using completion, or you can use a
+    context menu;
+\item The command is called on the arguments, usually resulting in
+    some significant modification of the data structure representing
+    your application logic;
+\item A \emph{display routine} is called to update the views of the
+  application logic.  The display routine may use features such as
+  incremental redisplay. 
+\end{itemize}
+
+Instead of attaching event handlers to gadgets, writing a CLIM
+application therefore consists of:
+
+\begin{itemize}
+\item writing CLIM commands that modify the application data
+  structures independently of how those commands are invoked, and
+  which may take application objects as arguments;
+\item writing display routines that turn the application data
+  structures (and possibly some "view" object) into a collection of
+  visible representations (having presentation types) of application
+  objects;
+\item writing completion routines that allow you to type in
+  application objects (of a certain presentation type) using
+  completions;
+\item independently deciding how commands are to be invoked (menus,
+  buttons, presentations, textual commands, etc).
+\end{itemize}
+
+By using CLIM as a mediator of command invocation and argument
+acquisition, you can obtain some very modular code.  Application logic
+is completely separate from interaction policies, and the two can
+evolve separately and independently. 
+
 \part{Getting Started}
 
 \chapter{CLIM Demos and Applications}