From: Robert Strandh <stra...@labri.fr>
Newsgroups: comp.lang.lisp
Subject: Re: Someone explain (Mc)Clim to me as if I were 5 years old
Date: 27 Oct 2006 07:03:27 +0200
Organization: Universite Bordeaux I
Lines: 95
Sender: stra...@serveur5.labri.fr
Message-ID: <6wodrywdsw.fsf@serveur5.labri.fr>
References: <1161824657.944988.261640@i3g2000cwc.googlegroups.com>
NNTP-Posting-Host: serveur5.labri.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.u-bordeaux1.fr 1161925422 16177 147.210.9.207 (27 Oct 2006 05:03:42 GMT)
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Path: g2news2.google.com!news4.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!novia!newsfeed.icl.net!proxad.net!feed.ac-versailles.fr!news.ecp.fr!news.u-bordeaux.fr!not-for-mail

"thetza" <the...@mm.st> writes:

> And to me, a GUI program is structured as follows:
> a. You create instances of different widget with various options,
> b. you lay them out in a geometry manager,
> c. you bind events to your widgets, and
> d. you start your event loop.

This is the way most programs using traditional GUI libraries are
structured. 

But that structure is an unfortunate side-effect of the low level of
those traditional GUI libraries.  By having to handle events, you no
longer have access to execution contexts such as the stack, and you
have to manage all kinds of contexts yourself, or else you end up with
applications that have a very rudimentary interaction policy. 

> Can someone compare and contrast McClim to the  more "traditional" gui
> toolkits, both in terms of its scope/purpose/goals and how McClim
> applications are to be structured?

CLIM turns the structure of traditional GUI libraries inside-out, and
makes it both possible and normal so use interaction methods that are
common in non-GUI based programs, i.e. where the program logic has the
initiative, and you use reads and writes to accomplish the
interaction. 

CLIM has a "command loop" that is at a higher level than an event loop
and that:

  * acquires a command.  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 ;

  * acquires the arguments required by that command.  These arguments
    are often associated with a "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 ;

  * calls the command on its arguments, usually resulting in some
    significant modification of the "model", i.e. the data structure
    representing your application logic ;

  * calls a redisplay routine (which might use incremental redisplay)
    to update your views of the model.

Writing a CLIM application therefore consists of:

  * writing CLIM commands that modify the model independently of how
    those commands are invoked, and which may take application objects
    as arguments ;

  * writing display routines that turns the model (and possibly some
    "view" object) into a collection of visible representations
    (having presentation types) of application objects ;

  * writing completion routines that allows you to type in application
    objects (of a certain presentation type) using completions ;

  * independently deciding how commands are to be invoked (menus,
    buttons, presentations, textual commands, etc). 

By using CLIM as a mediator of command invocation and argument
acquisition, you can obtain some very modular code indeed. 

But there is more.  CLIM is a well-documented and very rich collection
of internal protocols, and programmers can add, modify, or replace
components of CLIM by respecting those protocols, in particular the
programmer can:

  * use CLOS :before, :after, and :around methods on documented CLIM
    generic functions to modify the behavior of standard CLIM in
    interesting ways ;

  * add new types of panes and gadgets ;

  * modify the way presentation types are displayed, or the way they
    are sensitive to mouse gestures ;

  * add specialized output records for particular application needs ;

  * replace the standard command loop ;

  * etc, etc, etc.

-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------