Matej Knopp

> > The alternative for intrinsic height is shrinkWrap. As is common for other scrollable widgets. > > But `shrinkWrap` is a request, not a query, right? Whereas a `RenderBox`...

I tried running Superlist with this branch, and apart from making sure there are no render boxes outside of editor (which is a given) the only change I needed was...

Apologies for the delay. Right now trying to dogfooding this in superlist to figure out if there are some loose ends that need to be addressed in this PR.

The failing test is because of https://github.com/superlistapp/super_editor/issues/2056. By a coincidence the existing tests didn't catch the regression in main, but did catch it with changes in this PR.

@matthew-carroll, can you approve the PR?

@KevinBrendel, can you be more specific about the use-case? Do you calculate dry layout multiple times with different constraints or do you just need super_editor to take required height for...

@KevinBrendel, I think something like this should work for your use case: ```dart class FakeViewport extends SingleChildRenderObjectWidget { FakeViewport({required super.child}); @override RenderObject createRenderObject(BuildContext context) { return _RenderFakeViewport(); } } class...

If you don't have scrollable in hierarchy, SuperEditor will create a single child scroll view. I think maybe you'd need a way to disable this behavior completely since you don't...

I have not been looking into that. But I do think that with [OverlayPortal](https://api.flutter.dev/flutter/widgets/OverlayPortal-class.html) there *might* now be simpler (and probably better *) way to position popovers. I've proof of...

Data classes and JSON are pretty much orthogonal. To put them to same package for the sole reason of not having to do `dart pub add json` seems like a...