> But, I still have problems with overlapping output. I tried the
> clim:r-tree-output-history but this doesn't solve the problem.
> Actually, the behavior does not seem to be noticably different between
> the default output history and clim:r-tree-output-history.
>
> OK, my guess is that you are indeed moving the wrong record. You should
> probably be keeping track the UPDATING-OUTPUT record that each of your
> nodes live inside of, and move that record instead. Right now, you are
> clearly keeping track of the node output record; just keep track of the
> UPDATING-OUTPUT record that is just "outside" of it.
>
Like I said in a previous posting, *I* am not moving the output
record. CLIM is doing it for me thru incremental redisplay. That is,
I set the new position of the object, tick the object, and let
incremental redisplay update the objects new position on the screen.
Playing around with things a bit, and thinking over my lunchtime walk
(its a beautiful Indian summer day in Seattle), it seems that the way
UPDATING-OUTPUT is dealing with overlapping records may be buggy. For
example, say I have 3 objects that are drawn in succession (1, 2, and
3), non-overlapping with the following appearance:
+---+ +---+ +---+
| | | | | |
| 1 | | 2 | | 3 |
| | | | | |
+---+ +---+ +---+
If I move object 2 somewhere "over" object 3, object 2 is drawn over
object 3 but object 3's presentation record (as evidenced by what
mouse sensitivity does) is on top of object 2. That is, object 3 is
sensitive and highlighted even though its drawn image is (partially)
below object 2. If I force a complete redisplay object 3's drawn
image is on top of object 2. I suppose that CLIM attempts to try and
keep the time sequence in which things are drawn even in the face of
incremental redisplay. This seems to be done for the presentation,
but not for the drawn image. Of course, if I move object 3 over
object 2, everything is as it should be. The behavior is the same
whether I use the default :OUTPUT-RECORD for the display pane or a
CLIM:R-TREE-OUTPUT-HISTORY. (Sorry if this is a ACL CLIM bug rather
than a core bug if a bug at all.)
While rounding the corner of the river at lunch, it also dawned
(duhhhh) on me that there are other "orderings" that one may want to
enforce. For example, how would one move object 2 over object 3, then
bring object 3 to the "foreground" and have everything be displayed
correctly. I suspect that this "layering" would have to be kept track
of by the application and things REPLAY'ed appropriately. I further
suspect that one would want to pitch UPDATING-OUTPUT and "roll your
own" output record manipulations to enforce a layering mechanism.
BTW - I think that my trashed output was the result of how I was
drawing arc's between objects. I was drawing arcs at the same level
as the object's UPDATING-OUTPUT record rather than below. Essentially
I did:
(defmethod draw-object ((graph test-graph-ui-mixin) stream)
(loop for node in (graph-nodes graph)
do
(draw-object node stream)
(draw-arcs node stream)))
(defmethod draw-object :around ((node test-node-ui-mixin) stream)
(clim:updating-output (stream
:fixed-position t
:cache-value (node-tick node)
:unique-id node)
(call-next-method)))
(defmethod draw-arcs :around ((node test-node-ui-mixin) stream)
(clim:updating-output (stream
:cache-value (arc-tick node)
:unique-id (list node :arc)
:id-test #'equal)
(call-next-method)))
I suspect things will look better if a node "owns" its successor arcs
and are drawn under the nodes UPDATING-OUTPUT record.
ba