Adding a progress-bar widget #6517

Weibye · 2022-11-07T22:00:31Z

Objective

On our way to solve Bevy UI: High level targets for Widgets #5604 we need a lot of different widgets.
This attempts to add a progress-bar widget
Which can be used for loading indicators, health / mana-bars.

Solution

2022-11-07.22-47-29.mp4

Same as UI Slider Widget #6236, the general design-approach here is "Widgets as lose collections of hierarchies of bundles".
For the loading-bar widget to work, the user needs to create a NodeBundle with a ProgressBarWidget-component attached, that has a child NodeBundle with a ProgressBarInner-component.
It is completely up to the user to make sure these requirements are met.

Changelog

Added

Progress bar widget

Notes

Please critique this general approach. I know how we can setup a lot of other widgets the same way, but I have not yet any clear answers for the bigger-picture problems such as "widget composition" and "widget styling".
My gut feeling says it will be easier to tackle those problems once we have some real uses of various widgets in Bevy.

alice-i-cecile · 2022-11-07T22:14:50Z

@bzm3r review plz!

crates/bevy_ui/src/widget/loading_bar.rs

examples/ui/loading_bar_widget.rs

alice-i-cecile

Specific feedback about this widget:

genuinely useful
needs to be more robust to misconfiguration and alternate use cases: vertical orientation, LTR, etc
needs a name that encourages devs to use it as e.g. a life bar. ProgressBar maybe?
needs an example demonstrating how to use and position it in screen space (yeah I know this currently sucks)

General thoughts:

the "spawn complex trees of widgets" pattern is miserable. So much boilerplate, so hard to parse
updating the value of data within components is great
I worry about the poor scaling of O(n) change detection systems every frame for elements that rarely change. A push-based model feels more natural for thing like buttons
differentiating widgets of the same type is going to get annoying without general-purpose relations unless you use an event-based architecture (which is annoying in its own ways)
widgets really feel like they belong in their own bevy_widgets crate?
I really want to be able to disable / not include systems for widgets I'm not using in my game: the random perf loss every single frame bothers me

Weibye · 2022-11-08T07:59:36Z

widgets really feel like they belong in their own bevy_widgets crate?

We should also setup a new category of examples for widgets IMO. Should these two things happen in this PR, or somewhere else?

- Start cleanup

alice-i-cecile · 2022-11-08T13:50:24Z

I think in this PR: it's already going to be controversial, so let's do this right from the start.

- Add direction parameter

Weibye · 2022-11-08T19:47:42Z

Cargo.toml

@@ -67,6 +68,7 @@ bevy_scene = ["bevy_internal/bevy_scene"]
 bevy_sprite = ["bevy_internal/bevy_sprite"]
 bevy_text = ["bevy_internal/bevy_text"]
 bevy_ui = ["bevy_internal/bevy_ui"]
+bevy_widget = ["bevy_internal/bevy_widget"]


I don't really know if this is the correct setup, please let me know how to adjust.

Weibye · 2022-11-08T19:48:42Z

crates/bevy_math/src/lib.rs

+/// Maps a value from one range of values to a new range of values.
+pub fn map_range(value: f32, old_range: (f32, f32), new_range: (f32, f32)) -> f32 {
+    (value - old_range.0) / (old_range.1 - old_range.0) * (new_range.1 - new_range.0) + new_range.0
+}


Added this to bevy_math: Couldn't find anything that was already providing the same functionality but I may be mistaken.

How do we make this discoverable for others down the line?

How do we make this discoverable for others down the line?

Perhaps as an extension to either scalars or Range values, such that we can have either value.map_range(a..b, c..d) or (a..b).map_range(c..d, value)? In the former case the intervals are more intuitive (a..b is clearly the "old" range of value), whereas in the latter the arguments would be reversed, such that a..b becomes the output range.

IceSentry · 2022-11-09T21:42:44Z

examples/widgets/progress_bar.rs

+    // ui camera
+    commands.spawn(Camera2dBundle::default());
+
+    // background that fills the entire viewport


Is this necessary? Why not just use the default clear color of bevy? I'm not really against this, but just trying to see where the example could be simplified a little.

I guess you need the root node to take the whole screen to center the progress bar?

Yes. Previously we have been using auto-margin to centre elements on the page. This is not the best practice, see #6535. In order to centre the element you need the parent element to cover the whole area.

The root / background does not strictly need a background colour, I added it for stylistic choices but can remove it if desired.

ghost · 2022-11-10T22:46:22Z

I'd like to see support for generics for min, max, progress values if that is reasonable. (Most of my use of progress bars are based on {u,i}N values)

This implementation should likely be coordinating with the proposed UI slider widget WRT internal representation of progress.

Weibye · 2022-11-12T08:49:32Z

I'd like to see support for generics for min, max, progress values if that is reasonable. (Most of my use of progress bars are based on {u,i}N values)

I'm not too versed in generic rust yet, so I'm not entirely sure how that would look but if you'd provide a code snippet of what that would look like, I'm happy to include it :)

bzm3r

I like this.

bzm3r · 2022-12-07T02:21:35Z

crates/bevy_math/src/lib.rs

+/// Maps a value from one range of values to a new range of values.
+pub fn map_range(value: f32, old_range: (f32, f32), new_range: (f32, f32)) -> f32 {
+    (value - old_range.0) / (old_range.1 - old_range.0) * (new_range.1 - new_range.0) + new_range.0
+}


How do we make this discoverable for others down the line?

bzm3r · 2022-12-07T02:24:02Z

crates/bevy_widget/src/lib.rs

+
+impl Plugin for WidgetPlugin {
+    fn build(&self, app: &mut App) {
+        app.register_type::<ProgressBarWidget>()


I'm not sure about ProgressBar as a name. The core widget here seems to be much more general than just a bar for progress.

A rough idea for a more general/useful name: ResourceMeter? Not sold on that idea, but it is more general?

In general UI terminology, the name of the widget is usually "ProgressBar".

https://material.angular.io/components/progress-bar/overview

https://react-bootstrap.github.io/components/progress/

https://docs.unity3d.com/ScriptReference/UIElements.ProgressBar.html

https://docs.unrealengine.com/4.27/en-US/API/Runtime/UMG/Components/UProgressBar/

https://docs.godotengine.org/en/stable/classes/class_progressbar.html

A loading screen, a health bar, mana bar, XP bar, various resource trackers you find in games are just specific implementations of that widget.

bzm3r · 2022-12-07T02:26:36Z

crates/bevy_widget/src/progress_bar.rs

+    /// Creates a new [`ProgressBarWidget`].
+    pub fn new(progress: f32, min: f32, max: f32) -> Self {
+        if min > max {
+            panic!("Min should not be larger than max");


Would it be sufficient to just put an assert here? assert(!(min > max), "Min should not be larger than max")

Yeah that might be a better option

bas-ie · 2024-10-06T01:08:06Z

Backlog cleanup: closing due to inactivity, and in light of the significant development effort surrounding Bevy editor which will be surfacing any amount of new UI/widgets.

Adding initial loading-bar widget

1552af7

Weibye added C-Feature A new feature, making something new possible A-UI Graphical user interfaces, styles, layouts, and widgets labels Nov 7, 2022