Bevy's default App::update() is limiting for subapp workflows.

[moonheart08]

What problem does this solve or what need does it fill?

Currently you're restricted to Bevy's default update and extract workflow, which is limiting for more complex workflows using subapps.

What solution would you like?

Currently, the simple solution seems like the best solution, which is to allow the user to replace App::update() with their own function. This would allow the user to then iterate subapps themselves and manually call extract as needed.

What alternative(s) have you considered?

I honestly couldn't think of anything that couldn't just be implemented in terms of replacing App::update()

An explicit extract flow graph for example (to allow the user to specify which apps extract from where) could just be done with the above solution instead.

Willing to pick this up and implement it myself to meet the 0.16.x release cycle.

[JMS55]

Do you have an example of what you want to use this for? Hard to judge if it's a good idea or not without specific use cases.

[moonheart08]

Do you have an example of what you want to use this for? Hard to judge if it's a good idea or not without specific use cases.

The PR I ultimately made includes a convo that has an example.

Copying here:

[15:34]moony (Kaylie!): Is there some recommended way to customize the subapp update order? I'm doing my own shenanigans with extract and runtime addition of subapps and would rather not have the defaults.
[15:35]moony (Kaylie!): atm the blocker seems to be making whatever i do work with the existing winit code
[15:37]moony (Kaylie!): (I'm already targetting latest instead of stable due to needing .sub_apps() so if it's specific to latest that's still good to know)
[16:26]moony (Kaylie!): i have worked out a scrungly solution for the meantime: App in my App.
[16:43]Alice 🌹: Not really, this is kinda half-baked still
[16:43]moony (Kaylie!): just being able to replace update() with my own func would be sufficient tbh and likely covers most uses
[16:44]moony (Kaylie!): filing an issue about that approach atm
[16:45]Alice 🌹: Okay sweet; that's appreciated. We haven't done a ton of digging into the exact ways that users might want to extend / modify this design, so experienced-based opinions are really useful
[16:45]Alice 🌹: Mostly my reaction to subapps and windowing is :pain2: due to the difficulty testing and all of the platforms, so changes there are really slow currently
[16:46]moony (Kaylie!): my exact constraint is I'm adding some arbitrary N set of scene subapps for worlds the player could be in, and allowing the user to swap between them
this is very easy to do if i can just control which subapp render is running extract on (and otherwise control the extract flow myself)
[16:46]moony (Kaylie!): in other words a single "main" subapp isn't the right approach for my experiment
[16:47]Alice 🌹: Interesting. What's the ultimate motivation for that? For the most part my opinion is "don't use subapps if at all possible", and I'd generally use something like states and scenes or something for that design
[16:47]moony (Kaylie!): isolating those scenes, because UGC
[16:48]moony (Kaylie!): if one scene gets completely mucked up for whatever reason the user should be able to just close or leave it and be fine
[16:48]Alice 🌹: Aha, interesting! Okay, that makes more sense to me

As for why this cannot be done by not using update() at all, some plugins like WinitPlugin expect to be able to call update() themselves (as WinitPlugin provides its own runner)

Currently it is not possible to customize when extract runs and over which worlds, or view and modify app state (like the set of all subapps) during App::run().

[moonheart08]

I'm in too deep:tm:
The concept does in fact work in practice, however my exact goal (swapping between render scenes) is unfortunately not that easy due to having to work with various implementation details of rendering. Further work needed, this is a good start.