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

Question on the CAD-Demo

   Date:	Thu, 18 Nov 1993 10:13:15 -0800
   From:	clarisse@iexist.att.com

   Why is the CAD-Demo code (CLIM.*) really going through
   the trouble of defining it's own style of output-records
   and overriding methods for displaying output records etc.,
   and bounding-rectangle methods?

Back when I was writing that demo, the original idea was to show how
you could interface CLIM to an application that was ALREADY
maintaining a database of objects and had to have knowledge about
their appearance, location, etc.

One of the failings of Dynamic windows was that such applications
ended up with two copies of the graphical object database, one in the
application and a "shadow copy" in the window's output history (the
shadow history typically contains an output record or presentation for
each application object).  Of course, the one in the window history
was only a weak approximation of the original, so you were always
referencing back to the original objects, for example to invoke
application methods on them.

The CAD demo was a test bed for an approach in which you take your
application's pre-existing CLOS classes and "upgrade" them so that
they support the presentation protocol and could behave as
presentations.  Similarly, you would re-tool the application's object
store to substitute as the window's top-level output record, and write
"trampoline" methods for the various operations such as "what output
record is at this x,y coordinate" and so on.  The assumption was that
a program like a CAD editor would already have code to answer such a
question anyway.

Unfortunately, as you can see from the various internal clim::xxx
symbols in the demo, we never completely fulfilled the promise of this
scheme, but it is still a useful illustration of what can be done.

   I am really interested in what IS the most effective
   way to accomplish the same effect with possibly new
   features available in CLIM2.0.

It depends on what you mean by "same effect".  If you mean a generic
CLIM "graphical object" editor (which could be refined into a CAD
program, etc.) then I think that Scott has done quite a bit of work in
this area for CLIM 2.  If you mean the specific trick of integrating
a set of application objects with the output-record/presentation
mechanism, I don't think that this has gotten better in CLIM 2.  Maybe
some attention can be paid to this in that great future CLIM in the
sky in which the output record and sheet/gadget protocols are unified.
References:
Main Index | Thread Index