pb
pb copied to clipboard
setting message doesn't trigger re-draw
have to call tick() afterwards to get it to show the message
That should be the default behaviour
Why? It seems like if you set the message on a progress bar, that should be the message that's displayed?
Because double-redrawing every tick is really bad?
Code example of correct usage of ProgressBar::message()
// or, y'know, iterate over current dir, it's too early to do that so I hardcoded it
static FILES: &'static [&'static str] = &[".gitignore", ".travis.yml", "Cargo.lock", "Cargo.toml", "LICENSE", "README.md", "appveyor.yml", "assets/icon.png", "gh_rsa.enc", "not-stakkr.sublime-project", "not-stakkr.sublime-workspace", "rustfmt.toml", "src/lib.rs", "src/main.rs", "src/ops/init.rs", "src/ops/mod.rs", "src/ops/token.rs", "src/options.rs", "src/outcome.rs", "src/util.rs", "tests/mod.rs", "tests/util/mod.rs", "tests/util/prompt_exact_len.rs"];
let mut pb = ProgressBar::new(FILES.len());
for f in FILES {
pb.message(f);
pb.inc();
thread::sleep_ms(5);
}
Lol, thumbs down. Ouch.
Yeah, I get what you're saying, but the underlying issue around that seems like an architectural challenge of either having a transactional API or having an animation thread.
In my project, for example, I've wrapped pb
in a thread that animates at a specified framerate, and it queues up actions to be executed in the next display frame. Perhaps this is something pb
should just do to solve this problem.
I think we should leave as is.
None of the show/tick/message options trigger redraws upon changes.
I think there is merit in the approach suggested where a seperate thread updates the UX at a particular frame rate. However, that is a rather different approach to what pb is doing and would require a complete rearchitecture of the system. So, perhaps there is a place for a crate that does that, but pb isn't it.