Skip to content

General Progress representation for UI Widgets#6620

Closed
Weibye wants to merge 23 commits intobevyengine:mainfrom
Weibye:progress-struct
Closed

General Progress representation for UI Widgets#6620
Weibye wants to merge 23 commits intobevyengine:mainfrom
Weibye:progress-struct

Conversation

@Weibye
Copy link
Contributor

@Weibye Weibye commented Nov 14, 2022

Objective

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 Adding a progress-bar widget #6517 (review)) but there might be other, better places for it.
  • Consensus is that it should live in bevy_utils.

@Weibye
Copy link
Contributor Author

Weibye commented Nov 14, 2022

@AxiomaticSemantics, @Pietrek14, review please :)

Copy link
Contributor

@ManevilleF ManevilleF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

where
T: PartialOrd<T>,
{
pub fn new(value: T, min: T, max: T) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this function check if value is actually in range ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does, by calling the from_range(), which has the check.

@Weibye
Copy link
Contributor Author

Weibye commented Nov 14, 2022

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.

@Weibye Weibye changed the title General Progress representation General Progress representation for UI Widgets Nov 14, 2022
@Weibye Weibye added C-Feature A new feature, making something new possible A-UI Graphical user interfaces, styles, layouts, and widgets C-Usability A targeted quality-of-life change that makes Bevy easier to use A-Utils Utility functions and types labels Nov 14, 2022
@Weibye Weibye marked this pull request as ready for review November 14, 2022 20:46
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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to return any value. An Ok(()) should be enough here.

@alice-i-cecile
Copy link
Member

alice-i-cecile commented Nov 14, 2022

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.

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some doc nits. Additionally:

  1. This should live in bevy_utils
  2. Add, AddAssign, Sub and SubAssign traits.
  3. ProgressError type.
  4. progress_normalized -> normalized method name.
  5. percent() constructor method.
  6. Derive Clone and PartialEq on the struct.

@Weibye
Copy link
Contributor Author

Weibye commented Nov 14, 2022

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

Copy link
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's progress! Some feedback on tests, but once that's done this LGTM.

@Weibye
Copy link
Contributor Author

Weibye commented Nov 15, 2022

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

@Weibye Weibye requested a review from mockersf November 15, 2022 17:35
@Weibye
Copy link
Contributor Author

Weibye commented Nov 15, 2022

@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.

@Weibye Weibye requested review from ManevilleF, Pietrek14 and alice-i-cecile and removed request for ManevilleF November 15, 2022 21:02
@alice-i-cecile alice-i-cecile added the X-Needs-SME This type of work requires an SME to approve it. label Nov 26, 2022
@alice-i-cecile
Copy link
Member

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

@sixfold-origami
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor Author

Weibye commented Nov 27, 2022

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.

@Weibye Weibye closed this Nov 27, 2022
@Weibye Weibye mentioned this pull request Jan 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-UI Graphical user interfaces, styles, layouts, and widgets A-Utils Utility functions and types C-Feature A new feature, making something new possible C-Usability A targeted quality-of-life change that makes Bevy easier to use X-Needs-SME This type of work requires an SME to approve it.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants