add the pixels-per-scroll-step init argument
#4
Conversation
thanks to @alex-hhh for the actual implementation
|
This pull request has been mentioned on Racket Discourse. There might be relevant details there: https://racket.discourse.group/t/putting-a-large-pict-in-a-text-scroll-bar-problems/2700/5 |
See also racket/pict-snip#4 and connected discussion. The example program in the discussion is gone, but was trivial.
| @@ -18,9 +19,15 @@ | |||
| } | |||
|
|
|||
| @defclass[pict-snip% snip% ()]{ | |||
| @defconstructor[([pict pict?])]{ | |||
| @defconstructor[([pict pict?] | |||
| [pixels-per-scroll-step (or/c #f natural?) #f])]{ | |||
There was a problem hiding this comment.
Is the default value #f for backwards compatibility? Everyone who wants the different behavior (I suspect most people) will now have to specify the init argument explicitly for each snip they create. This requires writing more code, and I don't think the user would want different scroll steps for different snips in their application.
I think that pixels-per-scroll-step would better be a parameter outside the snip class. This way, we could keep the default of #f, but the user could put a single (pict-snip-pixels-per-scroll-step 1) call at the beginning of their program and switch to smooth scrolling for their application.
There was a problem hiding this comment.
Yes, the default was just the same behavior as before. I'm happy to change it, tho. (It seems legitimate to consider this a bugfix!)
As for the parameter, I'd prefer to just set the default to something we think will work well for people. But do you think there will be situations where two different values will be best and also where setting things globally like that will be useful?
There was a problem hiding this comment.
I'll note that in my case 1 was smoother but 10 meant less scrolling (on my trackpad) to actually see the image. So I stuck with 10 for now.
There was a problem hiding this comment.
Yes, I think it is better to consider this a bugfix. While it looks like different values for the scroll step might be needed for different applications, I don't think the previous behavior of not being able to scroll would have legitimate use cases.
@benknoble , I wonder if the text% (or editor-canvas%) implementation need to implement accelerated scrolling?
There was a problem hiding this comment.
Happy to try accelerated scrolling / help implement and test.
There was a problem hiding this comment.
There was some work back in 2019 that @Bogdanp and @mflatt did to improve scrolling and also some work in 2018. I forget when it was exactly but there was a big improvement at some point around that era where scrolling got some serious effort and got a lot better.
That said, there is definitely a lot more that can be done but poking around in the mred directory in gui-lib might turn up some code that you'd be able to spot improvements for!
thanks to @alex-hhh for the actual implementation