Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hidden as an attribute on Style not ProgressBar #623

Closed
akanalytics opened this issue Jan 24, 2024 · 3 comments
Closed

Hidden as an attribute on Style not ProgressBar #623

akanalytics opened this issue Jan 24, 2024 · 3 comments

Comments

@akanalytics
Copy link

Great crate!

The problem I am trying to solve is an easy way to hide a progress bar when logging or other more detailed diagnostics are enabled at runtime. Having both progress bars and logging makes things very messy on screen.

Right now I can use hidden attribute on a custom progress bar based upon conditions, and the remainder of the code stays the same .... except this is very clumsy.
IteratorExact uses iterator length, and my custom progress bar (activated with iter.progress_with) then loses the length estimate. So I end up with custom extension traits etc.

If hidden was an attribute of style, I could hide or unhide progress bars by changing their style, and install them on an iterator using iter.progress_with_style, retaining the length of the iterator.

Is there an easier way?

@djc
Copy link
Member

djc commented Jan 25, 2024

Right now I can use hidden attribute on a custom progress bar based upon conditions, and the remainder of the code stays the same .... except this is very clumsy.
IteratorExact uses iterator length, and my custom progress bar (activated with iter.progress_with) then loses the length estimate. So I end up with custom extension traits etc.

I'm not sure what you mean with all this. It seems to me you can use ProgressBar::set_draw_target() to ProgressDrawTarget::hidden() in most cases, I'm not sure why this isn't viable with your iterator setup.

@akanalytics
Copy link
Author

akanalytics commented Jan 29, 2024

This works - just sits strangely with the iterator API - so not a bug, more a comment on usability. Maybe it is because Im seeing things like "hidden" from a UI perspective.

Im used to "visible" or "hidden" being a UI-style attribute on screen components etc. For indicatif its not. Its an attribute of the bar.

For other style attributes, the idicatif API is really clean. ie

fn my_default_custom_style() -> ProgressStyle {
 // omitted logic setting colors etc
}

// many loops / lots of code using iterators etc. 
for item in collection.iter().progress().with_style( my_default_custom_style() ) {
   // loop logic
}
// similar code as ablove repeated many times with different containers/files/iterators etc

When I try and incorporate hidden, this becomes a bit clumsy. Hidden is not in style, its an attribute of bar.
I cant change my_default_custom_style to be my_default_custom_bar as this requires setting the length, and ProgressIterator::progress_with(my_default_custom_bar()) would then not take the length from the ExactSizeIterator. All solvable, and I can add a custom extension trait to Iterator to make it cleaner, but less of a "batteries included" experience.

Please don't read this as complaining :-)
Indicatif is a great crate.

@djc
Copy link
Member

djc commented Jan 30, 2024

I think this is a core part of the architecture of the crate -- if the progress bar is hidden we have to do less work. I would suggest you don't try to shoehorn your adapters in your pre-existing worldview that visibility is necessarily part of style.

I'm not motivated to work on changing this and fundamentally changing the API like this feels like it has an unclear cost-benefit trade-off so I'll close this issue.

@djc djc closed this as not planned Won't fix, can't repro, duplicate, stale Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants