Add a gizmo-based overlay to show UI node outlines (Adopted)

[pablo-lua]

Objective

• This is an adopted version of Add a gizmo-based overlay to show UI node outlines #10420
• The objective is to help debugging the Ui layout tree with helpful outlines, that can be easily enabled/disabled

Solution

• Like Add a gizmo-based overlay to show UI node outlines #10420, the solution is using the bevy_gizmos in outlining the nodes

---

Changelog

Added

• Added debug_overlay mod to bevy_dev_tools
• Added bevy_ui_debug feature to bevy_dev_tools

How to use

• The user must use bevy_dev_tools feature in TOML
• The user must use the plugin UiDebugPlugin, that can be found on bevy::dev_tools::debug_overlay
• Finally, to enable the function, the user must set UiDebugOptions::enabled to true
  Someone can easily toggle the function with something like:

fn toggle_overlay(input: Res<ButtonInput<KeyCode>>, options: ResMut<UiDebugOptions>) {
   if input.just_pressed(KeyCode::Space) {
      // The toggle method will enable if disabled and disable if enabled
      options.toggle();
   }
}

Note that this feature can be disabled from dev_tools, as its in fact behind a default feature there, being the feature bevy_ui_debug.

Limitations

Currently, due to limitations with gizmos itself, it's not possible to support this feature to more the one window, so this tool is limited to the primary window only.

Showcase

Ui example with debug_overlay enabled

And disabled

[alice-i-cecile]

Do we keep the keybinding config?

IMO no, this doesn't justify the complexity here (for now). Just make sure there's a good way for users to toggle it from their own code.

Is it a good idea to move this to bevy_gizmos instead of bevy_ui?

Definitely belongs in bevy_ui for now. If the plans regarding a bevy_debug_tools first-party crate come to fruition, this is another prime candidate for inclusion and should be moved there.

[pablo-lua]

IMO no, this doesn't justify the complexity here (for now)

Agreed, for now I'll remove the key binding, the user can easily enough enable or disable by setting DebugOptions::enabled = true / false.

[66OJ66]

It might be worth adding a toggle so that only Nodes which are children of a Visible root node have outlines applied.
(not too sure what the best approach would be though)

Reason for this: some Apps will create all their UI elements upfront under separate root nodes, then just show/hide these elements by changing the root node Visibility settings.

In this scenario, users could potentially see 100s of overlaid outlines which would make this new feature harder to use

[pablo-lua]

Added this, for now, It will hide the outlines of anything that is not visible judging by ViewVisibility component, let me know if you guys think that there is another better approach in this case

[pablo-lua]

Remembered about UiScale, I'll have a little look at it another hour, but this is a error so I'll throw this in draft until I fix it

[pablo-lua]

With this fixed, only thing that matters for now is adding some docs, I'm not very good at this, will try tomorrow 👍

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[pablo-lua]

I removed the feature from top level features. Added bevy_ui_debug as a feature of bevy_dev_tools, and now you have to add the plugin yourself, like in the example, but I'm not sure if thats alright, so I could use of another opinion on what we have now. I'll fix the CI now btw.

[alice-i-cecile]

Hmm, if we add a dev-dependency on bevy in the bevy Cargo.toml with bevy_debug_tools enabled does that work?

This may still be better, as it prompts users that the flag exists though.

[pablo-lua]

Hmm, if we add a dev-dependency on bevy in the bevy Cargo.toml with bevy_debug_tools enabled does that work?

This may still be better, as it prompts users that the flag exists though.

That does work, but that can be strange. If for some reason you enable the feature, the dev_tools plugin will be auto Added by the feature in DefaultPlugins, so I thought it would be strange to have the dependencies "duplicated" in examples
If that's okay, I can change it though, but like you said, there is value in have it as a feature IMO

[alice-i-cecile]

Yeah, I think this is better. Thanks for checking!

[github-actions]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

[pablo-lua]

You added a new example but didn't add metadata for it. Please update the root Cargo.toml file.

Third time in this PR.

[pablo-lua]

@alice-i-cecile Should be alright now, main Ci passed.