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

Question on the CAD-Demo

   Date:	Mon, 22 Nov 1993 08:14:29 -0800
   From:	clarisse@iexist.att.com

   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.

Glad we could help.

   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).

The assumption behind the CAD demo was that you were going to have to
implement an efficient "geographical search" algorithm (i.e. find
what's under the mouse) anyway if you were building something like a
CAD program.  The demo's main point was to show you how CLIM could
"keep out of your way" and let you capitalize on this domain-specific
code.  In the demo's case, the application-supplied search code is
pretty stupid.

   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?

Actually, since CLIM 2 now has an R-tree (or is it quad-tree?)
implementation, you could kind of turn the CAD demo example on its
head and instead borrow an R-tree output record to use as your
application's object store.  Then you would by definition have an
output record suitable for CLIM's use and you could use the regular
output record manipulation functions to get and put objects in the
store.

   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").]

Yes, unless you can borrow code from CLIM to accomplish that!

   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).

Not necessarily.  I think that you want to either 1) implement an
efficient application-specific object store, including the search
algorithm, and then wrap it in the CLIM output record protocol, or 2)
start with a CLIM output record class that already does efficient
search and then using it as the base class for your application's
object database.
References:
Main Index | Thread Index