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

Re: Question on the CAD-Demo

William, Scott:

Thanks to both of you for your replies.
When I first sent my query to clim@bbn I did not know who
wrote the CAD demo (I did not find any author name in the file).
Your responses made the intent and the contents of the demo
much clearer. It's actually a nice example (albeit, not simple)
of how you can override default CLIM behavior and have
your application take over parts of CLIM.

One question remains: how do you override the default
CLIM output record behavior and still take advantage
of CLIM optimization to locate objects that "own" the
mouse??

(defmethod map-over-output-records-containing-position
	   (function (cd cad-demo) x y
	    &optional (x-offset 0) (y-offset 0) &rest continuation-args)
  (declare (dynamic-extent continuation-args))
  (translate-positions x-offset y-offset x y)
  (dolist (object (slot-value cd 'object-list))
    (when (region-contains-position-p object x y)
      (apply function object continuation-args))))

For a cad like application containing several hundred
graphical objects, I am not sure this approach
is efficient enough. I saw some mail on the CLIM mailing list
about the use of special tree structure for output records
(I assumed to get efficient redisplay, highlighting,
and fast mouse selections).

Am I right to assume that by redefining CLIM output record
behavior as in the CAD demo I am also giving up the efficiency
of CLIM output record trees? And while this was an advantage
in CLIM 1.1 (on some implementations I tried), I may be loosing
in CLIM 2.0 where this type of optimization has been improved?

Am I also right to assume that the CAD demo style would need to
implement its own form of optimization for graphical redisplay
and mouse selections in order to win. [Where winning means:
maintain only one record of all graphical output for both
CLIM and the application DB and provide optimized redisplay,
and fast response to mouse selections for large number of
graphical objects ("records").]

Then isn't it true that you still need to have two storage
representations anyway (e.g. one DB optimized for your application
and one for graphical manipulation)? Therefore the best you can hope
for is sharing the leaves of your trees between the two
representations (application and GUI).

Olivier Clarisse

P.S. By the way, the CLIM 2.0 implementations I have seen are
     VERY impressive. Congratulations to the designers and implementors,
     it's high quality, flexible, efficient, quite robust, highly productive.
     I only wish I had switched from 1.1 to CLIM 2.0 earlier!

This reflects my personal opinion, not necessarily my employer's...
Follow-Ups:
Main Index | Thread Index