Fire events when scenes spawn

[szunami]

Objective

• Fixes Fire events when scenes spawn #2425

Solution

• Introduce SceneSpawnedEvent as the new event type. Open to a different name / structure; are there related events that should be considered?
• As part of spawn_queued_scenes, fire events when spawning scenes succeeds

Also, this is my first slightly larger code contribution, apologies if my style / approach is off :)

[szunami]

Actually spawning scenes requires a mut World, so I think this is necessary. Open to other approaches.

[alice-i-cecile]

bors try

[bors]

try

Build succeeded:

• check-missing-examples-in-docs
• check-markdown-links
• markdownlint
• build-wasm (stable, ubuntu-latest)
• build-wasm (nightly, ubuntu-latest)
• check-doc
• build (stable, windows-latest)
• run-examples
• build (stable, macos-latest)
• build (nightly, ubuntu-latest)
• build-android
• build (stable, ubuntu-latest)

[mockersf]

You should also send events when scenes are spawned with the sync methods (spawn_sync and spawn_dynamic_sync).

[szunami]

@mockersf so you'd prefer if the event were written inside the sync methods? Is there a case where the sync methods get called directly?

I didn't pursue this initially because we need to get an event writer via resource_scope; we could certainly do this in the sync methods, but I'm not sure what the ramifications of that would be. Is this your preference?

Alternatively, the sync methods could take an EventWriter as input or something like that.

[alice-i-cecile]

I didn't pursue this initially because we need to get an event writer via resource_scope; we could certainly do this in the sync methods, but I'm not sure what the ramifications of that would be. Is this your preference?

That's correct. There should be effectively no ramifications to that though: we already have &mut World (which contains our events) as a parameter on those methods, so we're not actually blocking any extra data.

In exchange, consistency and reliability are improved significantly. I definitely agree with Francois's proposal.

[mockersf]

@mockersf so you'd prefer if the event were written inside the sync methods? Is there a case where the sync methods get called directly?

They are public, so we don't know if anyone is using them directly... They are the only way to spawn a scene without waiting for a frame, so it makes sense to keep them public.

[szunami]

@mockersf I had another pass at this.

It is a little awkward that we event one event in spawn_dynamic_sync and the other in spawn_sync_internal; this seemed like the most natural way to do things given the way the code is layed out, but seems a little likely for one to be missed in future updates.

[mockersf]

Yup dynamic scenes are missing a few things that added complexity to non dynamic scenes... I changed some of that in #2424. Yours or mine will have to be updated whichever gets merged last (probably mine as yours is much simpler)

[alice-i-cecile]

bors try

[bors]

try

Merge conflict.

[cart]

Just left some thoughts in #2218. I'd like to discuss UX + api design a bit more before moving forward on this.

[cart]

Closing this out for now as I think we need to think about the comments in #2218 before designing this API. We can resurrect if this ends up being the right base for it.