I get an explained pict and then a GUI Easy-built widget displaying some text and the same pict (in a text%, via pict-snip%). But the scroll-bar won't let me scroll to where I believe the bottom of the editor is unless I make the window bigger.
In my application, I can't reasonably make the window bigger: I'd like to make the scroll bar work as I expect (that is, the bottom of the editor extends to the bottom of the pict in this example).
I mentioned in Discord that I tried baseless because I suspected the ascent line was the problem (see the "cutoff"). This had no apparent effect.
I now think the descent line is actually the problem based on the Pict docs and the code in pict-snip%, but I'm not sure how to adjust it.
Does anyone know what's actually happening here and how to fix it?
Probably the pict-snip% needs some options where it allows scroll steps inside itself in certain situations. I'm not sure what the best way to go is, but I believe the snip object is part of the story in the scrollbar.
To follow on from Robby's reply, pict-snip% needs to be extended with the get-num-scroll-steps, get-scroll-step-offset and find-scroll-step methods. image-snip% already impements those, so probably this is just an ommision that they are missing from pict-snip%.
Here is an example of how it would work:
#lang racket/gui
(require pict/snip pict)
;; pixels per scroll step, can be set 1 for smooth scrolling
(define ppss 10.0)
(define pict-snip-with-fixed-scroll%
(class pict-snip%
(init)
(super-new)
(define/override (get-num-scroll-steps)
(define height (pict-height (send this get-pict)))
(exact-ceiling (/ height ppss)))
(define/override (get-scroll-step-offset offset)
(exact-floor (* offset ppss)))
(define/override (find-scroll-step y)
(exact-floor (/ y ppss)))))
(define f (new frame% [label "Test Frame"] [width 400] [height 300]))
(define c (new editor-canvas% [parent f]))
(define t (new text%))
(send c set-editor t)
(send t insert (new pict-snip-with-fixed-scroll% [pict (disk 513)]))
(send f show #t)
I made the new argument default to a value that is the same as the current behavior. It might be better to default to something clever based on the line that the snip is in but I've not tried to see if that's something one can do via the snip admin interface or not. Defaulting to 10 is reasonable to me too, if folks think that's better.
Oh, sorry, @benknoble . I hope I didn't duplicate your work!
image-snip% uses a value of 50 (hard coded inside the module). plot-snip%, which is derived from image-snip%, also uses the same value. One option would be to use the value 50 in pict-snip% for consistency.
Another option would be to use 1 for both pict-snip% and image-snip%, and perhaps as the default scroll step for all snips, which would make the applications feel more modern, since smooth scrolling is used everywhere now. I experimented with a value of 1 (smooth scrolling) and seems to work fine (I have an older machine).
I tried it out too (on the same example you posted above) and I do agree that something small would work thanks to some improvements in recent years for trackpad scrolling and refreshing. But, for me at least, 2 seemed to feel a bit better than 1. What do you think of 2?
