[mcclim-devel] scrollbars and :command-loop
Hi, I have an application pane with :display-time :command-loop, inside a (scrolling ...) form. For the most part, in this application, it is likely that the contents of this pane after a redisplay are similar to those before: so, I would like to be able to preserve the viewport position across redisplays. I've come up with the following method on redisplay-frame-pane: (defmethod redisplay-frame-pane :around ((frame gsharp) (pane gsharp-pane) &key force-p) (declare (ignore force-p)) (let ((transformation (sheet-transformation pane))) (multiple-value-bind (x y) (window-viewport-position pane) (multiple-value-bind (x1 y1) (untransform-position transformation x y) (call-next-method) (setf (window-viewport-position pane) (values x1 y1)))))) which meets the spec, I suppose -- I don't know how well-defined it is, but it does what I wanted it to in McCLIM. However, it leads to visual artifacts: the call-next-method here eventually calls (window-clear), which resets the space-requirements and the transformation of the sheet, which means the scrollbars change size; then the whole of the redraw takes place, and only then does the viewport's position get reset. My question then is twofold. Firstly, is this a sensible thing to be doing at all, or is there some other mechanism for achieving what I want here? (Incremental redisplay might be it, but that has some other problems in this application). Secondly, is there a way of eliminating these glitches? Cheers, Christophe
I struggled with this a while ago and concluded that incremental redisplay is probably the intended solution.
[added gsharp-devel, since that's where this patch would end up...] "Andy Hefner" <ahefner@gmail.com> writes:
I struggled with this a while ago and concluded that incremental redisplay is probably the intended solution.
While Andy said this in this forum, he did provide a hint in another... on IRC, he said <hefner> Xof: have you considered solving your scrolling problem by setting :display-time nil and calling your display function yourself from the top-level loop and using (clear-output-record (stream-output-history foo)) rather than window-clear? And so I tried it, and the attached patch is the result. I don't know if it's climily correct, and it might suffer a bit from suboptimality when loading in new files, but apart from that it does what I think I want it to. So this patch does two things: one, after doing what drawing to the score pane needs to be done, the :height space requirement is changed to whatever it needs to be; two, window-clear calls are intercepted and implemented following Andy's suggestion. Comments? Cheers, Christophe
participants (2)
-
Andy Hefner
-
Christophe Rhodes