Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How could I extend BoxyChild? #10

Closed
MikeFP opened this issue Sep 28, 2021 · 8 comments
Closed

How could I extend BoxyChild? #10

MikeFP opened this issue Sep 28, 2021 · 8 comments
Labels
question A question and not an issue

Comments

@MikeFP
Copy link

MikeFP commented Sep 28, 2021

I'm trying to expose an extra property on BoxyChild so the parent delegate can use it in its layout. I tried to understand the overall structure of the Boxy classes but couldn't wrap my head around it. So my question is:

Is it possible to extend BoxyChild and instance it as a child of a CustomBoxy? How could I accomplish that?

My final goal is to build a Widget kinda like OverflowPadding, except that it exposes the child's fullRect (including the overflow) as well. If that should only be possible with a custom RenderObject, please let me know.

@pingbird pingbird added the question A question and not an issue label Sep 28, 2021
@pingbird
Copy link
Owner

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

image

@MikeFP
Copy link
Author

MikeFP commented Sep 28, 2021

@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
Copy link
Owner

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
Copy link
Owner

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

@MikeFP
Copy link
Author

MikeFP commented Sep 28, 2021

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
Copy link
Owner

pingbird commented Sep 28, 2021

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?

@MikeFP
Copy link
Author

MikeFP commented Oct 1, 2021

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:
issue-layout

Example with ornaments around children:
issue-layout-problem

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:
issue-layout-after

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
Copy link
Owner

Moving to #24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question A question and not an issue
Projects
None yet
Development

No branches or pull requests

2 participants