How could I extend BoxyChild? about boxy

[MikeFP]

Here's an example.

I have a column containing children with some padding between them. The children themselves are containers with dynamic height that may have some "ornaments" floating around them, which initially could be Positioned children of a Stack. The ornaments are also dynamic, and thus, only know their size after layout.

Basic structure:

Example with ornaments around children:

The problem is that sometimes those ornaments overlap, which is not desired. I'd like to increase the padding accordingly only if there are overlaps. And for that, I need to know the rects of those ornaments, or worst case scenario, the rect of the column children including the ornaments, so I can compute the minimum amount of padding necessary so they don't overlap.

Desired result after pushing overlaps:

The real problem though is not laying out the children. A Stack can do it just fine. What I need is access to the child rect during layout phase including the space of floating children.

[pingbird]

The framework makes very strong assumptions about how data is passed between RenderObjects during layout, specifically, only constraints can go down and only geometry can go up, any communication outside of that would break layout optimizations.

Adding more properties to the geometry (Size / SliverGeometry) would require writing a RenderObject subclass and handling its new protocol in the parent.

Luckily if the information is known during build, you can just use parent data: https://gist.github.com/PixelToast/2d51cc484d9a7a6a15c1bd405712a3d4

[MikeFP]

@PixelToast I see. In that case, I think I'll have to dive in custom RenderObjects.

While I'm at it, may I ask if using a lot of GlobalKeys to access deep nested children impacts on performance or is just not a good practice in general?

[pingbird]

The only significant cost to GlobalKey is when its used to reparent the child widget, accessing it alone is usually fine.

You shouldn't use it to access descendants during layout though, that would break a lot of the assumptions the framework makes (there are a bunch of assertions that should prevent you from doing that too).

[pingbird]

Also the gist I posted above implements what I thought you wanted to do, and it doesn't require subclassing RenderObject.

[MikeFP]

In my use case, I don't know the size of the children during build time.

Actually, what I'm looking for is more accurately described as a Stack with non-positioned children whose size are not know until layout.

[pingbird]

The gist doesn't rely on the size of the child being known at build time, only OverflowingChild.padding

Do you have a diagram or example of the layout you are trying to achieve?

[pingbird]

Moving to #24