Layout within Scroll

[jneem]

I would like to have the child of a Scroll widget take up at least the visible area of the Scroll, but I can't figure out how using the current API.
As a motivating example, suppose I want to write a note-taking app with infinite scrolling. I try to do this by putting a Drawing widget inside a Scroll. Initially, I want the Drawing to take up the whole visible area of the Scroll but no more. As the drawing gets bigger, I want it to be scrollable. The issue is that there doesn't appear to be a way for Drawing's layout function to know how big the Scroll is: it just gets to see unconstrained bounds.
For example of what is done elsewhere, Flutter has a sort of custom layout protocol within scrollable widgets.

[cmyr]

yes, I've been thinking about this in the past couple days; the current ways to achieve this are hacky, like having a parent widget of the Scroll send its size down to the inner widget in a Command. I'm not sure what the best approach is, will do some looking.

[ForLoveOfCats]

I've got a half baked scrollbar PR sitting around right now which allows scrollbars to be inlay instead of painting over the child content and this is very close to an issue I'm having. When adding content to a Scroll in the list example it to now require a vertical bar which shortens the child's paintable width so it also requires a horizontal scrollbar until the next time a layout occurs at which point the children will know the correct width. (I need to open this as a draft)

I also want to expand to the Scroll's size in my text editor project so any ideas on how to improve this would be awesome

[cmyr]

yea, there are a few things here.

I think one simple improvement is to make Scroll pass its 'actual' size as the min constraint to its children; currently children have no constraints.

For this to make sense, we also want to make sure scroll has a clear size? Does it make sense for the size of the scroll widget to be determined by the size of the child? I think maybe not; maybe the scroll should always have a fixed size (and so be passed tight constraints?)

[luleyleo]

I think it would make sens for Scroll to pass down its own min size as min constraints but still shrink itself to this size of its child. When we want the Scroll to take up the available space it could always be wrapped in a SizedBox using WidgetExt::expand right?

[cmyr]

yes, I think that makes more sense.

[ForLoveOfCats]

I've been putting a bit of thought into this over the past few days as I continue to exercise the scroll widget in my text editor project and I've come to the conclusion that perhaps scrolling should be some kind of functionality that widgets should be able to embed in themselves somehow. Split up the functionality and let widgets pick and choose which parts to use. I'm not sure what level of abstraction is most suitable but some scroll building blocks would be handy.

This would allow the generic scroll widget to continue to exist (albeit calling out to these scroll building blocks) but there can also be more focused scrolling widgets re-using this same functionality (such as vertical lists). This is important as some widgets need a closer tie to their scrolling behaviour such as text edit widget which needs to know/manipulate the current scroll value as well as take up the full space or a tab bar which might want to reuse the scrollbar rendering but have different behaviour.

Perhaps I'm barking up the wrong tree with this idea but I think it has some merits and I'm interested to hear other's thoughts on it

[cmyr]

I think something like this makes sense; we would break the scrolling stuff up into a "clipping widget" and then the mechanics of actually scrolling. the clipping widget would be some widget that shows an offset region of a child.

[ForLoveOfCats]

Closing in favour of #73