This works but isn't very efficient. The IndexedStack builds all of them right at the beginning. Don't know if there's something reusable to not build them until needed.

Yeah we definitely don't want to use an IndexedStack here.
...
...
(long in-person discussion)
...
...
We concluded we want to use a Stack, lazily inflate the children so that you only inflate them once they've been picked, then keep them in the tree, and you want to use TickerMode and Offstage to keep them cheaper.

Maybe instead of a Stack use a CustomMultiChildLayout so you can stop them being laid out as well.

Maybe I'm misapplying it. Did you mean give it a MultiChildLayoutDelegate and have it just layout and position the active tab only? I'm getting

The _TabViewLayout custom multichild layout delegate forgot to lay out the following child:
  1: RenderOffstage#1048774387 NEEDS-LAYOUT NEEDS-PAINT
Each child must be laid out exactly once.

Or did you just mean to layout all the children with the delegate but don't do any complex calculations, just let them have the size of the parent all the time?

i think you got a merge error here

Thanks

we normally call this copyWith()

...and list all the arguments. Search for examples of "copyWith" to crib from.

Ah right, should have remembered the convention. Thanks

this seems dangerous... what if you keep applying it to the object you get back? Eventually you'll have this really long chain of callbacks...

ya, made the copyWith generic, put the logic to the caller in scaffold

s/the/a/

done

are built

done

Usually you want the first paragraph to be just one sentence. The first paragraph is what ends up being used as the "short doc" in the API doc summaries.

done

missing comma before "is"

thanks

and and

thanks

this last sentence is confusing. I'm not sure it's worth including, honestly, but if you do want to be explicit about this I think it needs to be clearer what this means.

reworded

[.tabbed] should be [new CupertinoScaffold.tabbed] I believe

Thanks! Adam told me once but I forgot how it worked

offline chat summary:
Make a custom private mechanism that uses offstage, tickermode and a custom lazy builder

motivations:

• lazy build initially
• stop animations for offscreen
• keep offscreen subtrees alive

Thanks

Ah right, should have remembered the convention. Thanks

ya, made the copyWith generic, put the logic to the caller in scaffold

done

done

thanks

thanks

Thanks! Adam told me once but I forgot how it worked

reworded

Maybe I'm misapplying it. Did you mean give it a MultiChildLayoutDelegate and have it just layout and position the active tab only? I'm getting

The _TabViewLayout custom multichild layout delegate forgot to lay out the following child:
  1: RenderOffstage#1048774387 NEEDS-LAYOUT NEEDS-PAINT
Each child must be laid out exactly once.

Or did you just mean to layout all the children with the delegate but don't do any complex calculations, just let them have the size of the parent all the time?

nit: here and below, put the colon on the same line as the }), as in

}) : tabBar = null,
     rootTabPageBuilder = null,
...

Done. I must have triggered the formatter without selecting a text range at some point

i think this would be easier to read on one line...

oops, drive by change. I gotta find a way to disable the formatter

We should also rebuild it if we've ever built it before, otherwise we'll be leaving stale widgets in the tree and no way to remove them (e.g. suppose one is a video, and the build function only includes the video if the tab is active -- if you don't rebuild the tab, you'll be leaving an active video and no way to remove it).

I was hoping we can keep it as simple as possible let the user handle edge cases by listening to their own supplied tab bar's onTap callbacks if needed.

But I think I may have to address it anyway with some version of solution to the problem you're describing in the next PR once I start putting in the Navigators. I think I'd like to tie that API together with the various page routes' maintainState concepts etc.

Adding todo to the issues

These aren't edge cases. The contract when you have a builder is that you'll call it any time you build. Putting in old widgets is going to be a weird quirk that will lead to bugs. We should just call the builders.

It's fine to not call them until you need them, but once you're including them, you should call them (or not use a builder).

ok, done.

nit: extraneous space

done

the docs for child and rootTabPageBuilder should clarify that they can't both be non-null, that one must be non-null, and they should each point to the relevant constructor.

done