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

updating-output CLIM 2.0

  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
Follow-Ups:
Main Index | Thread Index