I have been finding that my application-panes look to be off in width by the width of their scroll-bars. When I look at the COMPOSE-SPACE definitions (these are a little overwhelming for a novice like me) it looks like the effective method for compose-space for an application-pane is this one:
(defmethod compose-space ((pane clim-stream-pane) &key width height) (let ((w (bounding-rectangle-width (stream-output-history pane))) (h (bounding-rectangle-height (stream-output-history pane)))) (make-space-requirement :width w :min-width w :max-width +fill+ :height h :min-height h :max-height +fill+)))
This one doesn't have the potential for adding the width of scrollbars. Does this look like the right fix?
(defmethod compose-space :around ((pane clim-stream-pane) &key width height) (let ((inner-width (call-next-method))) (with-slots (scroll-bars) pane (cond ((null scroll-bars) inner-width) ((eq scroll-bars :vertical) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'vscrollbar)))) ((eq scroll-bars :horizontal) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))) (t (space-requirement+ inner-width (space-requirement+ (compose-space (slot-value (pane-scroller pane) 'vscrollbar)) (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))))))))
On Thursday, May 19, 2005, at 10:57 pm, Robert P. Goldman wrote:
I have been finding that my application-panes look to be off in width by the width of their scroll-bars. When I look at the COMPOSE-SPACE definitions (these are a little overwhelming for a novice like me) it looks like the effective method for compose-space for an application-pane is this one:
(defmethod compose-space ((pane clim-stream-pane) &key width height) (let ((w (bounding-rectangle-width (stream-output-history pane))) (h (bounding-rectangle-height (stream-output-history pane)))) (make-space-requirement :width w :min-width w :max-width +fill+ :height h :min-height h :max-height +fill+)))
This one doesn't have the potential for adding the width of scrollbars. Does this look like the right fix?
(defmethod compose-space :around ((pane clim-stream-pane) &key width height) (let ((inner-width (call-next-method))) (with-slots (scroll-bars) pane (cond ((null scroll-bars) inner-width) ((eq scroll-bars :vertical) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'vscrollbar)))) ((eq scroll-bars :horizontal) (space-requirement+ inner-width (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))) (t (space-requirement+ inner-width (space-requirement+ (compose-space (slot-value (pane-scroller pane) 'vscrollbar)) (compose-space (slot-value (pane-scroller pane) 'hscrollbar)))))))))
I don't think stream panes should know anything about scroll bars; these belong to the scroller pane rather than the stream pane I think (i.e. the stream pane doesn't want to ask for more space to account for scroll bars, rather the scroller pane should add space for bars to the space requirement of the stream pane on its behalf).
That said I tend to find my ideas of what's what are often incorrect ;-)
-Duncan
mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
"DR" == Duncan Rose duncan@robotcat.demon.co.uk writes:
DR> On Thursday, May 19, 2005, at 10:57 pm, Robert P. Goldman wrote:
>> >> I have been finding that my application-panes look to be off in width >> by the width of their scroll-bars. When I look at the COMPOSE-SPACE >> definitions (these are a little overwhelming for a novice like me) it >> looks like the effective method for compose-space for an >> application-pane is this one:
[...snip...]
DR> I don't think stream panes should know anything about scroll DR> bars; these belong to the scroller pane rather than the stream DR> pane I think (i.e. the stream pane doesn't want to ask for DR> more space to account for scroll bars, rather the scroller DR> pane should add space for bars to the space requirement of the DR> stream pane on its behalf).
DR> That said I tend to find my ideas of what's what are often DR> incorrect ;-)
I don't exactly understand. All I know is that my application panes are clipped to the right in a way that really suggests to me that McCLIM is trying to display an area w wide, and that it's computing the w based on the width of the output record, and then it's display w starting from the outside of the scroller-pane, so that what is displayed is actually w - (width scroller-pane).
This was the best guess I had for how to fix it. :-(
Maybe this lives in the incremental redisplay protocol, rather than the space requirement protocol.
I'm still bamboozled by the fact that adding incremental redisplay to my APPLICATION pane badly gaffed the rendering of my INTERACTOR pane, whose definition changed not a whit...
Anyone else have any clues?
Thanks, R
If it's not a compose-space problem, I'm wondering about the code in incremental-redisplay.lisp. Could it be the case that
(defmethod incremental-redisplay ((stream updating-output-stream-mixin) position erases moves draws erase-overlapping move-overlapping) (declare (ignore position)) (let ((history (stream-output-history stream))) (with-output-recording-options (stream :record nil :draw t) (loop for (nil br) in erases do (erase-rectangle stream br)) (loop for (nil old-bounding) in moves do (erase-rectangle stream old-bounding)) (loop for (nil br) in erase-overlapping do (erase-rectangle stream br)) (loop for (nil old-bounding) in move-overlapping do (erase-rectangle stream old-bounding))) (loop for (r) in moves do (replay r stream)) (loop for (r) in draws do (replay r stream)) (let ((res +nowhere+)) (loop for (r) in erase-overlapping do (setf res (region-union res r))) (loop for (r) in move-overlapping do (setf res (region-union res r))) (replay history stream res)) ))
Does the Wrong Thing when the STREAM argument is an application pane, ignoring the viewport stuff, and so the region operations are done with the wrong bounding area? In particular, it seems like the draws are clipped, possibly because the region-union doesn't take into account the scroll-bar area.
This is just a theory, and actually doesn't feel quite right to me. But I'm bamboozled for why the stream has this odd clipping. Can anyone confirm or disprove it? Better yet, does anyone have a better theory to offer?
Thanks, R
-
Duncan Rose -
Robert P. Goldman -
rpgoldman＠real-time.com -
rpgoldman＠sift.info