-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add fixed width bar bar_width and chop overflow on ncols
#716
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
Conversation
904af0d to
6d87a40
Compare
Codecov Report
@@ Coverage Diff @@
## master #716 +/- ##
==========================================
+ Coverage 98.86% 98.89% +0.03%
==========================================
Files 10 10
Lines 790 818 +28
Branches 143 150 +7
==========================================
+ Hits 781 809 +28
Misses 5 5
Partials 4 4 |
6d87a40 to
7f4092c
Compare
- added bar_width to initializer and format_meter that sets a fixed bar width that never changes (unless:) - added better ncols handling for overflows on l_bar, bar, r_bar specifically, output is restricted to one line (of length ncols) and will be chopped to ensure that is always true - added tests This fixes tqdm#623 This fixes tqdm#690 This helps prevent the spillover seen in tqdm#630
|
@casperdcl anything else I need to do with this to get it moving? |
bar_width and chop overflow on ncols
- supporting `{bar:[width][type]}` format string
- fixes #623
|
Regarding the clutter: I was just following the pattern that was existed when I wrote this code. It solves a serious issue that I could not get around by allowing the left, bar, and right sides of the progress bar to be set to a fixed width that cannot change. I've never seen the progress bar jump or duplicate itself on multiple lines since I put this in place. I've been using this for over 4 months, and it is (or at least, was...) properly tested, but since it was not actioned and the master code has moved forward, it looks like I'll need to spend more time on it, but I'd like to know it would be considered before I spend that time as it's difficult to schedule right now. |
|
@jeking3 don't worry about spending time on this; I'll rebase your commits in a new PR and ping you. Can't promise when as I don't get paid for this :P |
This fixes #623
This fixes #690
This helps prevent the spillover seen in #630
This option (bar_width) prevents the bar portion of the output from being resized dynamically, and makes the r_bar portion dynamic (it gets chopped). This addresses some of the concerns of #630 as well, but does not make an individual bar multi-line capable. It just ensures you do not get multiple lines.
If the l_bar side is larger than ncols, you get ncols of l_bar.
If l_bar + bar is larger than ncols, you get l_bar + some of the bar.
If t_bar + bar + r_bar is larger than ncols, some of r_bar gets chopped.
Is there anything else I need to do for this to be accepted?
Thanks.
read the known issues
environment, where applicable: