Move the already existent tools into bevy_dev_tools and creation of new ones

[pablo-lua]

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

After #11341, we now have a canonical place to store our native tools in a better way

What solution would you like?

The moval of the following tools:

- Aabb gizmos: #12354
- Light gizmos

• System stepping
• Camera controller
• Fps counter: Fps overlay #12382

And the creation of the new tools, like the following ones:

• Ui layout overlay: Add a gizmo-based overlay to show UI node outlines (Adopted) #11237
• Pipeline statistics: Integrate pipeline statistics with bevy_dev_tools #12541
• Diagnostics overlay: Diagnostic overlay dev tool #12560
• Schedule visualizer: Add a first-party schedule visualizer #10981
• Epilepsy warning: Tool for detecting potential triggers for photosensitive epilepsy during dev/playtest #8863
• Gpu timing overlay: Render node GPU timing overlay #8067

What alternative(s) have you considered?

None

Additional context

Message related of which tools we can try to move first:
https://discord.com/channels/691052431525675048/789987800014651412/1215063888064938064

See #11341 for more information.

[alice-i-cecile]

Can you update your message with a checklist of tools so we can track them as they get moved? :) These should be moved one tool at a time, to ease burden on reviewers and make sure things don't get stuck pointlessly.

[pablo-lua]

I did a little checklist here. Let me know if there is anything that can be improved :)

[pablo-lua]

I added Light Gizmos to the checklist: Noticed that this is a debug tool and even adds a plugin to the app

[mockersf]

I disagree on moving some gizmos to the dev tools. It should be either all of them or none, and I think I would prefer none.

We could move the mechanic to draw them automatically for all entities, but the gizmo themself should stay with the others

[pablo-lua]

I disagree on moving some gizmos to the dev tools. It should be either all of them or none, and I think I would prefer none.

We could move the mechanic to draw them automatically for all entities, but the gizmo themself should stay with the others

I agree here that moving something like the ArrowBuilder don't make sense: after all, they are just a "line composer", if I can say that. However, that's not the case of the Aabb gizmos and Light Gizmos: they are plugins Added by the user when they enable bevy_gizmos, they add systems and "event trackers" to entities to drawn above entities automatically, and they even have resources to enable that behavior or disable. So, IMO, those two In specific are exactly the meaning of dev tools.

[alice-i-cecile]

Yeah to me those two are "dev tools that happen to be built using gizmos". Like Pablo says, there's a qualitative difference between those two and the remaining gizmos.

Just like we shouldn't put "dev tools built using UI" in bevy_ui, I don't think these belong in bevy_gizmo either.

[matiqo15]

I would add:

• FPS counter - Requires small modification
• Camera controller
• UI layout debug - I'm not sure about this one
• Add a first-party schedule visualizer #10981
• Tool for detecting potential triggers for photosensitive epilepsy during dev/playtest #8863

[pablo-lua]

Ui Layout debug

I don't think this can be here, because this isn't much of a tool, even if it works for debugging. And It use some fields in types that aren't public. This can be solved, But I don't see much a reason to move it in bevy_dev_tools for now.

I think FPS counter can be a controversial decision. But I agree that its a tool and can be moved.

[alice-i-cecile]

FPS counter is high on my list :)

I think that the UI layout debug should be refactored so it can fit well into this crate.

[pablo-lua]

I changed this issue to track new tools too. If there is anything that I forgot, feel free to comment here
:)

[alice-i-cecile]

We should probably restrict the scope of this issue to "PRs that are already open": otherwise we'll never manage to close it :) Ideas for new features deserve their own issues.

[cart]

I disagree on moving some gizmos to the dev tools. It should be either all of them or none, and I think I would prefer none.

I agree. I think there are better paths:

1. Move gizmo implementations next to their features (ex: bevy_sprite defines its own gizmos)
2. Create a new bevy_editor_gizmos crate to be the home for bevy editor gizmos.

"gizmos" are a clear enough feature slice that putting them in the bevy_dev_tools grab bag feels wrong.

[pablo-lua]

Blocked on the RFC
See bevyengine/rfcs#77