General `Progress` representation for UI Widgets

[Weibye]

Objective

• Both the SliderWidget #6236 and the ProgressBarWidget #6517 are going to need some representation of progress.
• As we've discussed in those PRs, it would make sense to have both of them use the same underlying representation.

Solution

• This attempts setting up that underlying and general representation of progress. It is indented to solve the needs of the widgets but ideally would be suitable for additional purposes such as gameplay or loading.
• Additional identified use-case: Getting Progress from a Task in a AsyncComputeTaskPool

---

• ~~Please review and critique both the design but also where to place it. Maybe bevy_ui is not the best place for this in the long term?~~
• ~~My intention is that this will be moved over to the bevy_widgets-crate once that gets set up (see https://github.com/bevyengine/bevy/pull/6517#pullrequestreview-1171184009) but there might be other, better places for it.~~
• Consensus is that it should live in bevy_utils.

[Weibye]

@AxiomaticSemantics, @Pietrek14, review please :)

[Weibye]

Interesting tooling, I wonder if having Num as a trait bound would be useful, as it probably will always be numeric

That is probably a very reasonable assumption. I can't think of any use-cases where this would not be a number of some kind.

@ManevilleF Is there any Num traits in the std lib? I can only find mentions of num-traits and I'm a bit hesitant to pull additional dependencies in for this use case.

[alice-i-cecile]

It is indented to solve the needs of the widgets but ideally would be suitable for additional purposes such as gameplay or loading.

With this in mind, I would actually consider sticking it in bevy_utils? Folks who are using a different UI solution should feel okay importing this.

[Weibye]

Moved everything to bevy_utils and I think I have addressed all comments. feel free to add more :)

[Weibye]

Additional use-case: Getting Progress from a Task in a AsyncComputeTaskPool

[Weibye]

@mockersf Could you please have a look at this from a "general utility across the engine"-perspective? I'm sure you have some valuable insight.

[mockersf]

@mockersf Could you please have a look at this from a "general utility across the engine"-perspective? I'm sure you have some valuable insight.

I'm not sure it's really needed to have a common abstraction for that, and I see even less the need for it to be generic...

[alice-i-cecile]

Controversial label added because while this is well-made, it's not entirely clear it's worth the complexity.

[sixfold-origami]

I took a quick look at this, and honestly it doesn't really seem necessary. I really don't think "what percentage full is this thing" is not a complicated piece of functionality to abstract over. Over in traditional UI, we've been doing just fine without a special construct for progress, since percentFill: f32 works just fine in nearly all cases.

Additionally, I think this abstraction will quickly start to get applied to too many different use cases to still be meaningful. In my experience, this sort of functionality quickly has its meaning diluted as it's improperly applied to different contexts. Already, I would argue that input sliders and loading bars are two separate areas that don't need to be coupled.

[mockersf]

Already, I would argue that input sliders and loading bars are two separate areas that don't need to be coupled.

Speaking of "progress" for a slider doesn't make much sense...

[Pietrek14]

I think this would be useful, else we would have to repeat this logic in Slider (#6236) and ProgressBar (#6517), which is not the end of the world, but I would much rather have it as a seperate struct. This is a common enough use-case to probably appear in future UI widgets, so rewriting the same thing in all of them could be pretty cumbersome.

As to the name, I feel like calling the slider value "progress" isn't that uncommon, though I don't mind if the name is ultimately changed.

[Weibye]

Thanks for all the feedback! Conclusion is to close this and use a normalized float value of "progress" 0.0..=1.0 for the UI elements.

This can always be reopened if there's a different need where this is the right tool for the job.