General Progress representation for UI Widgets#6620
General Progress representation for UI Widgets#6620Weibye wants to merge 23 commits intobevyengine:mainfrom
Progress representation for UI Widgets#6620Conversation
|
@AxiomaticSemantics, @Pietrek14, review please :) |
ManevilleF
left a comment
There was a problem hiding this comment.
Interesting tooling, I wonder if having Num as a trait bound would be useful, as it probably will always be numeric
crates/bevy_ui/src/lib.rs
Outdated
| where | ||
| T: PartialOrd<T>, | ||
| { | ||
| pub fn new(value: T, min: T, max: T) -> Self { |
There was a problem hiding this comment.
Should this function check if value is actually in range ?
There was a problem hiding this comment.
It does, by calling the from_range(), which has the check.
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 |
Progress representation for UI Widgets
crates/bevy_ui/src/lib.rs
Outdated
| pub fn set_progress(&mut self, new_value: T) -> Result<T, &str> { | ||
| if self.bounds().contains(&new_value) { | ||
| self.value = new_value; | ||
| Ok(self.value) |
There was a problem hiding this comment.
I don't think you need to return any value. An Ok(()) should be enough here.
With this in mind, I would actually consider sticking it in |
alice-i-cecile
left a comment
There was a problem hiding this comment.
Some doc nits. Additionally:
- This should live in
bevy_utils Add,AddAssign,SubandSubAssigntraits.ProgressErrortype.progress_normalized->normalizedmethod name.percent()constructor method.- Derive
CloneandPartialEqon the struct.
|
Moved everything to |
alice-i-cecile
left a comment
There was a problem hiding this comment.
There's progress! Some feedback on tests, but once that's done this LGTM.
|
Additional use-case: Getting |
|
@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. |
fd7c7e2 to
e98edb5
Compare
|
Controversial label added because while this is well-made, it's not entirely clear it's worth the complexity. |
|
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 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. |
Speaking of "progress" for a slider doesn't make much sense... |
|
I think this would be useful, else we would have to repeat this logic in 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. |
|
Thanks for all the feedback! Conclusion is to close this and use a normalized float value of "progress" This can always be reopened if there's a different need where this is the right tool for the job. |
Objective
SliderWidgetUI Slider Widget #6236 and theProgressBarWidgetAdding a progress-bar widget #6517 are going to need some representation of progress.Solution
Progressfrom aTaskin aAsyncComputeTaskPoolPlease review and critique both the design but also where to place it. Maybebevy_uiis not the best place for this in the long term?My intention is that this will be moved over to thebevy_widgets-crate once that gets set up (see Adding a progress-bar widget #6517 (review)) but there might be other, better places for it.bevy_utils.