[mcclim-devel] pathology in updating output with format-graph-from-roots

[rpgoldman at real-time.com]

[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?