[discussed on #lisp, to no avail...]

If you look at http://rpgoldman.real-time.com/goofy-clim.png you will see what happens when one of my panes runs a display-function that calls format-graph-from-roots inside updating-output. The display does not all get updated, leaving funny gray borders around the active area of two panes.

What's interesting is that this pathology affects the interactor pane at the bottom of the layout, as well as the application pane at the top.

Before I made the display function for the top pane, the interactor pane used to function correctly. Now it erases its contents after every command, and has the gray border problem.

I almost wonder if my adding :incremental-redisplay t to the application frames could have somehow bled over into the options used in initializing the interactor pane....

Finally, even with updating-output, using format-graph-from-roots does not correctly relize that it needs a horizontal scrollbar as well as a vertical one, when it gets a new graph in it.

Some partial solutions:

1. Make application-panes with :scrollbars :both. I think this is actually a McCLIM bug. The spec states that the default value for application panes should be T (and it is), but also that T should be the same as :both (which doesn't seem to be an available option, according to the spec). So, somewhere we're treating :both and t differently, but I think they should be the same.

2. Use the bounding rectangle for the graph-output-record that format-graph-from-roots returns to set the :min-height and :min-width of the enclosing window, for example:

(defun graph-mdp (stream &optional (mdp (taems-mdp *application-frame*))) (when mdp (let ((normal-ink +foreground-ink+) (arrow-ink *graph-edge-ink*) (text-style *graph-text-style*)) (declare (special normal-ink arrow-ink text-style)) (let* ((graph-output-record (with-drawing-options (stream :text-style text-style) (format-graph-from-roots (list (taems:initial-state mdp)) ;; printer #'draw-mdp-node ;; inferior-producer #'taems:mdp-successors :stream stream :arc-drawer #'clim-internals::arrow-arc-drawer ))) (rect (bounding-rectangle graph-output-record))) (change-space-requirements stream :min-width (bounding-rectangle-width rect) :min-height (bounding-rectangle-height rect)) graph-output-record))))

[this function will be invoked wrapped in updating-output.]

That seems to get the scrollbars to be oriented to the right height and width.

I know that Andy has said that he doesn't like the idea of having format-graph-from-roots automagically call change-space-requirements, for the reason that it could cause too much wasted computation. As a programmer, though, having a function that is this high-level, but then requires low-level messing with output records and the fairly cryptic and ill-documented change-space-requirements seems very odd.

I suspect that my use of change-space-requirements is just plain wrong. My case up above is trivial, because my pane will ONLY have the graph in it; heaven help me if I ever want to stick a graph onto a scrolling output history pane or something... There ought to be (and probably is) some way of saying to the pane "hey, please make room for this big bolus of fresh, piping-hot pixels," but I don't understand the protocol well enough to say what it is...

But neither of the above fixes the weird gray stuff, which seems to be some flavor of updating error, and likely too deep in the guts of the system for the likes of me. Any suggestions for how I should start?