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

Re: updating-output CLIM 2.0

    Date: Fri, 28 Aug 1992 10:26 EDT
    From: Jeff Morrill <jmorrill@BBN.COM>

    [In the next round of CLIM documentation, it would be nice to see an example
    of something like this!]

Indeed, JGA and I plan to do this.

    I'm not sure the jury is in on updating-output.  You need it most when the
    display is NOT CHEAP to generate.  Suppose for my 100,000 point graph I want
    to change the units from "Fortnights" to "Furlongs".  Walking the output
    history is not expensive as long as there is a caching-point that encapsulates
    the entire 100,000 points of data, so that clim doesn't have to inspect each point.

    Although updating-output works OK for relatively simple displays, when you
    don't really need it, I have had terrible luck with complicated displays.
    In my opinion it is too slow and too buggy.  Nevertheless, I find myself using
    it (though not for graphs).  In defense of the implementors, it is a hard thing
    to do for the general case.  

Without trying to defend any of us implementors, it really is hard to
get UPDATING-OUTPUT to work really well, really fast.  UPDATING-OUTPUT
is presently worse than it should be in both respects, but I just don't
know how we are ever going to get it to be as good as we would all like
it to be.

    I think everyone feels that there is "excess junk" in clim, but nobody seems
    to agree about which parts are the junk.  Each feature makes some constituency
    happy.  If the specification is not going to get smaller, then I would like
    to see CLIM broken into libraries.  For example, all those color symbols
    (+white+ etc) should probably be put into a file that can be loaded if
    you need it, but if you don't need it your lisp image will be that much
    smaller.

This is all true.  The folks at Franz Inc have been thinking about this.
References:
Main Index | Thread Index