CLIM mail archive
[Prev][Next][Index][Thread]

updating-output CLIM 2.0

    Date: Thu, 27 Aug 1992 13:30 EDT
    From: "Ben A. Hyde" <gensym!bhyde@harvard.harvard.edu>

      I'm reading the CLIM Release 2.0 Specification, May 6, 92.  While I'm not
    a CLIM user, I've built a huge amount of UI over the years and I'm finding
    it very interesting.  Lots of questions come to mind, but let me start with
    one.
      Updating-output is very like a construct I've used in other programs, i.e.
    you write a routine that displays your output.  Then you discover that you
    want that same routine to do other things, like update the screen when the
    underlying document changes.  The operations enabled by having a path of 
    unique-ids, and a cached-value (aka update tick) are also a UI trick I've 
    seen in many programs.
      It is hard to tell in CLIM what features are excess junk piled on to
    please the ivory tower, and verses the stuff added to clarify
    the performance and interface.  For example I'm am not surprized 
    that designs are a superclass of regions.  This more of a problem for
    people who haven't actually built a complex UI.
      In anycase, my question.  Is it necessary to entangle the rich output
    records with the concept of updating-output.  In system's I've built it
    is cheap to generate the output.  That building, maintaining, walking,
    etc. any backing store is expensive and slow.  In system's I've built the
    concept of updating output use the screen bits as it's only output cache.
      I'm having trouble developing an affection for CLIM's rich backing store.
    Most programs I've been involved in do not maintain an output cache (other 
    that the screen bits), and I'm having trouble seeing that it is necessary.  
    Couldn't the routine captured by updating-output provide all the services 
    that the output record is?  I've always it asked to.
      - ben hyde, Gensym Inc. Cambridge


UPDATING-OUTPUT is a relatively straight-forward extension on top of the
rest of output recording.  So are presentations, which require more than
"just bits" to do their work.  So are the other high-level formatted
output tools.  So I am not sure how exactly to answer your questions.

But the fact that some UI systems have only the screen bits as what you
call an "output cache" is one of the problems with those UI systems.
Even raw X Windows has more than that -- there are all those window-ish
things floating around.  CLIM output recording provides the ability to
retain the *intention* of the program output, not just the bits.  When
used for presentations, this frees the programmer from having to manage
all of the usual application-specific bookkeeping himself (especially
the stuff related to using the mouse to point to stuff on the screen).

It is simple to either turn of output recording if you don't need it, or
special output recording to take advantage of application-specific
knowledge, too.  But ultimately, if your applications do not require
what CLIM has to offer, you shouldn't use CLIM.  (That's not meant to be
a sour grapes statement -- for some things, CLIM is just too much.)

BTW, there is basically nothing in CLIM to please anybody in any ivory
tower.  Almost everything is there to solve a real-world need, although
some things are more specialized and/or less successful than others.
References:
Main Index | Thread Index