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

[pablo-lua]

Objective

• This is an adopted version of #10420
• The objective is to help debugging the Ui layout tree with helpful outlines, that can be easily enabled/disabled

Solution

• Like #10420, the solution is using the bevy_gizmos in outlining the nodes

---

Changelog

Added

• Added debug_overlay mod to bevy_ui
• Added bevy_ui_debug feature

How to use

• The user must use the bevy_ui_debug feature
• The user must use the plugin UiDebugPlugin, that can be used with DefaultPlugins (Or adding The UiPlugin)
• 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();
   }
}

Keeped the line system itself like the old PR

[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 👍

[pablo-lua]

Added to the Ui examples, one must run cargo run --example --features ui bevy_ui_debug to see the feature (after quick search didn't found a way to enable this by default, if there is a way let me know =D ). One note is that its impossible to run this without fixing #11320, so its required to fix this at least temporarily to run this locally

[JMS55]

I think this should go in bevy_dev_tools https://github.com/bevyengine/bevy/pull/11341

[pablo-lua]

I think this should go in bevy_dev_tools

Agreed, but should we Block this until the bevy tools get merged (#11341)? (I think we should, but that depends on the PR situation)

[pablo-lua]

After the big changes on Ui, I noticed that some errors showed up, fixing them now 🔧

[matiqo15]

should we Block this until the bevy tools get merged (#11341)?

I don't think there is a need for that. We can move it later - it's probably going to take some time to get #11341 merged.

[pablo-lua]

After some digging found out that this will going to be a hard migration, So I want to collect you guys opinion The major problem is, we spawn a Debug Camera, which the user is not aware of. This wouldn't be a problem before, because we disabled the ui on that camera, but now every camera is a potential camera for ui (because we removed UiCameraOptions), so this would lead the user to add the TargetCamera to all nodes (at least, all the root nodes), even if they only spawned one camera and I think the easiest way to fix this behavior is by adding again the UiCameraOptions to skip this debug camera in specific (Correct me if I'm wrong on this aspect)

Now, something that must be decided: What we do about the different windows Ui? I think the easiest way to manage this type of thing is by spawning an different debug camera to each window (or by spawning a different camera at least for each target camera that has a different window itself), but what are you guys opinion on this design?

[pablo-lua]

Created #11377 to discuss this problem

[pablo-lua]

Merging #10342 would be the ideal solution to this problem, enabling and disabling only the debug lines in specific.

[alice-i-cecile]

Linked PR is merging: no longer blocked :)

[pablo-lua]

Found a new panic, for now #11420 is blocking.

[pablo-lua]

Hmmm, dont quite get the Dependencies error, didn't changed anything in dependencies...

[matiqo15]

Hmmm, dont quite get the Dependencies error, didn't changed anything in dependencies...

Seems to be failing since 35ac1b1

[pablo-lua]

Got it, thanks. Well, I'll open this PR for review, everything is working on new updates.

[pablo-lua]

Forgot to say: Due to the limitations with windows of bevy_gizmos, I limited this tool to the primary window only, I don't have any idea in particular of how to do this work on the currently API 🤔

[matiqo15]

Forgot to say: Due to the limitations with windows of bevy_gizmos, I limited this tool to the primary window only, I don't have any idea in particular of how to do this work on the currently API 🤔

We should mention it in docs

[github-actions[bot]]

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

[pablo-lua]

I'll throw it in a draft until I move this to the new bevy_dev_tools (see #11341)

[github-actions[bot]]

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[bot]]

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.