Implements conversion from SystemId to Entity

[porkbrain]

Objective

Right now when using egui, systems are inserted without any identifier and to the root. I'd like to name those systems and insert them as children to a root entity. This helps to keep the editor organized.

Solution

• Although the SystemId is documented as an opaque type, examples depicted above benefit from tear down of the abstraction.

---

Changelog

Added

• Implemented From<SystemId> for Entity

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[alice-i-cecile]

I'm a little nervous about doing this, as we may end up breaking this functionality in the future. But I can see the value in your use case.

What if we inserted the Name component to all system entities that matched the system name instead?

[pablo-lua]

What if we inserted the Name component to all system entities that matched the system name instead

Basically, insert the name of the given system on the entity?
for example: If I register the system "foo", the entity will have name "foo"

[porkbrain]

Thanks for getting back to me so quick!

What if we inserted the Name component to all system entities that matched the system name instead?

Adding the Name component automatically would be great. However, I am not sure how to go about it given that bevy_ecs does not depend on bevy_core that exports it. Any pointers to help me with this welcome.

Right now, I am using about a dozen registered systems (to modularize dialog logic), so automatically naming them is sufficient. However, inserting more and more registered systems would eventually warrant a root entity under which I hide all those systems. My plan was to cmd.entity(root).add_child(system_id.into()).
This is purely cosmetic: have egui organized and named instead of a long list of unnamed Entity items.

In any case, if your intuition says it will be refactored in the future, feel free to close the PR, it's a nice-to-have.

[pablo-lua]

IMO, would be good to support some kind of API to help the user, even if this will be refactored in the future
I have an Idea of how to implement something like that, but that would be a little different from the original proposal of inserting the Name

we would first spawn the entity with a given bundle (the user would give the bundle to the function)
something like register_system_with<B: Bundle>(bundle: B, system: /*...*/)
Then, I'm remembering of the register_boxed_system_with_entity (Big name) that was first implemented on a early version of this PR, that would pretty much help with this Bundle insertion (See #11019)
But thats only an Idea that I had

[alice-i-cecile]

Hmm right, it's stuck over in bevy_core. Even though this is likely to get refactored, I think this is a reasonable direction. @maniwani is hoping to make all systems entities one day, so this would still be effectively possible.

[alice-i-cecile]

I think we should improve these docs, but I'm on board.

[maniwani]

I think this is OK to allow since the component holding the system trait object is still private.

That said, having visible components will make system entities easier to match in queries, so it'll be easier for someone to delete them by accident, so I guess just watch out for that.