CLIM mail archive


question on table-formatting + graphics

   Reply-To: jmorrill@BBN.COM
   Date: Fri, 17 Jun 1994 14:55:39 -0400
   From: Jeff Morrill <jmorrill@BBN.COM>

     From: John Aspinall <>
     Date: Fri, 17 Jun 1994 14:40:59 -0400
     Cc: clim@BBN.COM
     Subject: question on table-formatting + graphics

     Cause of the problem: using the default type of output-record -
     coordinate-sorted-sets.  You're not really interfering with the table,
     just confusing the output-record lookup *above* the table.
     Coordinate-sorted-sets are assuming that no record inserted in the
     history after the table will overlap the table.  It's a bug.

     Easy workaround (CLIM 2 only, alas): Use an r-tree-output-history for
     the work-area pane.
     (define-application-frame test-editor ()
       (:command-table (top-level-test-ct))
	 :default-text-style '(:fix :roman :normal)
	 :display-function 'display-structure
	 :output-record (make-instance 'r-tree-output-history) ;; <== !
	 :incremental-redisplay nil
	 :scroll-bars ':both))

     Then it works for me.  (Lispworks 3.2, our "Beta 7" CLIM 2.)


   If we took all the money we've individually spent rediscovering this
   bug, we could have quite a party.  There is some bug in coordinate-sorted-sets
   where the output records don't get sorted correctly.  When that happens,
   mouse sensitivity goes haywire and so does incremental redisplay.

   I am dismayed that coordinate-sorted-sets are the default for panes.
   Whenever I have reasonably tricky graphics, I always override the default.  

I am perfectly willing for anyone to take a stab at fixing this bug
properly.  A few people have tried, but the fixes have either been
either incorrect or extremely costly.

As Jeff points out, a better default for graphics panes is the R-tree
output history.


Main Index | Thread Index