Open DeflatedPickle opened 5 years ago
I now realize that there is in fact a lot of overlap between this issue and issue #9. I am doing ore testing, and it turns out I have more I need to do until that PR can be merged... but I had a question for you @DeflatedPickle Nim:
Consider the case where the file is so large that it cannot fit into one page of the Scrollable widget. In this case, if the user "tabs over" to the Scroll widget and presses DOWN
, we need to decide if this should advance the cursor by one line in the file or by one tick of the Scroll Bar (which can and will imply skipping much further ahead in the text of the Scrollable widget). If we go with the former version (advance by only one line) then that would mean a user pressing DOWN
on the Scroll Bar won't neessarily advance the scroll button, but if we go with the latter version, then we probably want to offer a different method by which the user can "scroll by only one line" for convenience (going further down in the actual Scrollable Widget would be intuitive, but it doesn't work this way as currently written).
I'd be happy to implement either version -- I do love maths, after all :smile: -- but I thought I should ask what your vision is for it.
It shouldn't be hard to add a ScrollMethod
interface/class (enum?) to Scrollable
that'd be delegated to when scrolling, so I think both routes can be done. But I really don't want to maintain any C++ code and it would be rewritten in Kotlin/Multiplatform should it ever be updated by me
The scrollbar handles don't increment properly over the widget and aren't always properly sized. They also don't have scrolling caps, so scrolling too far will crash the program if there's no more content to scroll to.