@LongCatIsLooong Any chance you can merge this to tip of tree? I tried checking out the branch but I got a lot of merge conflicts.

So I tried this out yesterday and by and large it seems to work as expected (which is impressive! Wow!). However, I think we need to separate out the conduit API from Overlay. Having them be tied too closely leads to all kinds of problems, for example you can't use Positioned in the overlayChild.

The other weird thing about this API is that if you have multiple children you want to move to elsewhere in the tree you need one widget for each one. That took me a while to understand. Once I got the hang of it I was able to work with that easily enough.

Here's the code I wrote to experiment with this: http://junkyard.damowmow.com/606

I think I need to do more experiments, but I'd like to wait to have a version that isn't tied to the Overlay before I do that.

any updates? Can we merge this?

Oh ok, I see it's just in progress :) gtk

I like this new approach. I need to try playing with it.

@LongCatIsLooong points out for (3) that when the Leader is pushed down, its nodes are (temporarily) removed from the tree which also removes the children from the Follower, so it actually reduces to case (1).

So really all we need to do is make sizedByParent prevent the layout() call from laying out the children immediately.

Looking at the test failures, this probably requires a rebase to make cirrus happy.

@Hixie @goderbauer I tried out the "throw sizedByParent children back to the dirty list after performResize" trick in ec0680107f76148e9e6f7eebb437c19f12e91f86. The new tests are passing but some existing tests started to fail.

It seems some render objects need not only the size of their child but also the child's layout, e.g. render objects that call their child's getDistanceToActualBaseline. In this case we can't defer the child's performLayout even if it's sized by its parent.
Does it make sense to add a flag to RenderObject that indicates whether the parent is allowed to use the child's layout, or add it to RenderObject.layout (so it becomes something like void layout(Constraints constraints, { bool parentUsesSize = false, bool parentUsesLayout = false }))?
A quick search for "implements Render" in the registered tests yielded nothing.

If both subtrees are dirty and the Conduit branch lays out first, does making the anchor sizedByParent causes the layout of the remote branch to happen twice (triggered in both subtrees)? I guess we want to make the Conduit node deeper instead?
The current road blocker is when a ConduitAnchor is deferred to the next layout iteration, its descendant render objects that are also in the dirty list will be laid out more than once. I'll see if we can defer these nodes to the next iteration too.

@LongCatIsLooong Do you think there still is a path forward for this PR? Are you still working on it?

Yes I'm still (not very actively) working on this. I think it may still be doable, just need to find an approach that requires less crazy framework changes.

@Hixie @goderbauer all the tests seem to be passing now. Could you take a look? I added a shouldDeferLayout getter and a markDepedentNeedsLayout(RenderObject) method to RenderObject.

The portal is trying to achieve the same thing except it replace the overlay with an entire different system Portal. Why do we prefer one over the other?

I can answer that question:
Because portal was implemented outside of Flutter. So I was unable to modify Overlay, and instead made a fork.

Although if it were to be merged into Flutter, it could still be valuable to separate them, to help the migration.
Kind of like Router vs Navigator

The goal is the conduit widget is not responsible for laying out or paint its remote child.

In the rework branch, the mechanism is slightly different.

The conduit does the layout of the overlay entry (where the constraints are obtained with an object equivalent to LayerLink).
And the Overlay does the painting of the entries
This way it does not rely on having a specific layout order to work (so no situation where the widget may build twice like @Hixie mentioned).

Although I'm not sure if this has undesired side-effects

@rrousselGit Thanks for the explanation! I think the current implementation in the rework branch will probably break RenderObject.getTransformTo (and maybe some other things that rely on the hierarchy of the render object tree), nonetheless it looks really promising! It makes more sense to me to paint somewhere else than to move render objects around. 👍

@rrousselGit Thanks for the explanation! I think the current implementation in the rework branch will probably break RenderObject.getTransformTo (and maybe some other things that rely on the hierarchy of the render object tree), nonetheless it looks really promising! It makes more sense to me to paint somewhere else than to move render objects around.

It did, but I managed to fix it (it's in the branch)

My biggest worry was about RepaintBoundary & co, wondering if there isn't an edge case where the UI doesn't refresh or something

Haven't found anything so far though.

@rrousselGit no I'm just trying to reduce the number of open PRs since I'm currently not working on this.

What remains to be done?

Between Hero/package:animation issues, state restoration, and provider having difficulties, I think it's quite important and may continue it myself.