Hidden as an attribute on Style not ProgressBar about indicatif

[djc]

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]

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]

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.