Warn if there is no UI camera

[jakobhellermann]

fixes the UI part of #1432.

A system is added to POST_STARTUP which checks whether the world contains any Nodes but no ui cam and logs

WARN bevy_ui: The world contains ui nodes but no ui camera. Consider spawning a UiCameraBundle.

To opt out, a ValidationConfig is added to bevy_core. IMO adding a separate resource for every future validation system (e.g. #1439) would quickly become too complicated.

[DJMcNab]

I think opting out of this should be a setting on the UIPlugin, not in bevy_core. bevy_core should not be required to know about its dependents.

[jakobhellermann]

I kinda agree, but on the other hand I feel like one central place to configure these kinds of warnings would be nice.

Since the UiPlugin is usually initialized using DefaultPlugins, how would you set this on the UiPlugin?

[jakobhellermann]

The only viable alternative I saw was adding UiValidationConfig, TransformValidationConfig, RenderValidationConfig etc.

[DJMcNab]

Since the UiPlugin is usually initialized using DefaultPlugins, how would you set this on the UiPlugin?

You'd set it on the UIPlugin when you add the plugin group, using whichever incantation is correct to replace a plugin in a plugin group with itself but with additional data when you add it. I can't be bothered to look this up right now, and it's very unintuitive.

PluginGroup is a painful abstraction, but it's what we're stuck with at the moment, and we should work within it.

[cart]

I think my ideal solution is to make the UiCamera completely optional (and fall back to a default value). Most people don't need control over the UI camera, so theres no real reason to dictate one (other than the fact that its easier to require one because that behavior is consistent with the other render passes). Given that theres some design tradeoffs here, maybe its better to just move directly to an "optional ui camera" model?

[cart]

PluginGroup is a painful abstraction, but it's what we're stuck with at the moment, and we should work within it.

Ive been pushing us toward a "resource as configuration model" over "configuring plugins during construction model" for a number of reasons: #1382 (comment)

Imo users configuring Plugins in their constructor should be considered an anti-pattern.

[jakobhellermann]

That's reasonable, I'll close this then.