Make grid layouts easier

[Levi-Lesches]

For context, by the way, this is the application I'm working on.

It supports 1, 2, 3, 4, or 8 displays, all with customizable sizes. To make things more complicated, the 8-display has an unmovable barrier at the halfway point representing a physical hardware division.

To make a setup like this work, I use multiple containers and controllers. For example, this 8-cell layout is actually two columns, each with two rows, each with two columns again. That's a lot of controllers to manually sync up, and the build() function is very different for each configuration. Trying to change from an 8-cell layout to anything else, and then trying to set their ratios, results in errors around a mismatch of children and ratios. My current workaround is hooking into the Flutter framework and waiting for exactly 3 frames to pass to give the resizable containers enough time to recalculate. Happy to share more if needed.

It would be nice if there could be something like a ResizableGrid that takes a list of lists, or a crossAxisCount like Flutter's GridView does. It would probably come with its own controller that would make setSizes much simpler compared to my current method.

[andyhorn]

Wow, this is quite a layout! I'm sorry it's throwing so many errors - I never imagined a scenario like this haha.
I agree that something like a ResizableGrid would be really useful here.

I've been working on another feature request (for a ResizableSize.shrink()) where I have taken a similar approach to allowing Flutter to handle the layout by waiting a frame and then updating the child sizes. I was hesitant to release it because it adds an asynchronous dependency, but it might be necessary for these more complex layouts.

[Levi-Lesches]

Yes that might be needed! You can steal this if you'd like:

  /// Waits for the next frame to build.
  Future<void> nextFrame() {
    final completer = Completer<void>();
    SchedulerBinding.instance.addPostFrameCallback((_) => completer.complete());
    return completer.future;
  }

And now it's as simple as await nextFrame(). Full disclosure I don't actually know the full ramifications of addPostFrameCallback() vs scheduleFrameCallback().

Let me know if you have any ideas on this, I'd be happy to pitch in as it would save me and my team a lot of hacky code in our repo. I imagine the API could look like GridView.extent() in that it could be a one-dimensional list (and probably a new type of controller).