This looks like the right thing. Have you tried any benchmarks of the impact on text output speed (for, say, writing 10,000 lines of text to the pane)? I've feared that reinvoking the layout algorithm (and resizing the CLX mirror, etc) for each line of output would wreck the already unsatisfactory performance in this case. In many cases (commands or display functions printing substantial output) it would be advantageous to let the output be generated in a batch, and resize the sheet pane once when it completes. This is a different pattern of usage than the lone application-pane which is only written to occasionally, but certainly the programmer should not have to fuss with manually resizing the pane in the latter case. OTOH, this seems like exactly what changing-space-requirements is for. So long as the appropriate places (execution of command bodies, pane redisplay) in McCLIM are surrounded by this form, performance should not be impacted. There is an alternate approach whereby growth of the bounding rectangle of a sheet output history would trigger an automatic resize of the sheet. This is clean and appealing, and would work for all manner of output besides text, but I've come to think that for some applications (graphics..) the ability to clip output within the sheet region is a feature rather than a bug. On 2/16/06, Troels Henriksen <athas@sigkill.dk> wrote:
Troels Henriksen <athas@sigkill.dk> writes:
Does anyone else have a better solution?
Attached to this post is a patch to stream-output.lisp that fixes the issue and doesn't cause horrible breakage (AFAICS). -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)
_______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel