ui: very short progress bar

[Suor]

On master branch.

Steps to reproduce:

• create a dvc repo
• create a directory of 150 moderately large files, say 10mb
• dvc add them

The progress bar looks like 10 chars in width.

[efiop]

@Suor something like a screenshot would be helpful to assess the severity. 🙂

[pared]

I had the same issue with my latest test, and its not only add.

https://asciinema.org/a/267948

[casperdcl]

yes this was a design introduced in #2436, specifically https://github.com/iterative/dvc/pull/2436/files#diff-b4d487abdc2dca03a19e8e4a7bceccf2R39

This was included due to the ugly looking misalignment of progress bars on top of each other (i.e. one bar with width 20 followed by another width 10 don't align nicely visually).

@efiop perhaps we don't need this any more since the bars are being cleared away so we never see them on top of each other any more?

[efiop]

Thank you @pared 🙏

@casperdcl We might bring some of those back, though, right? Maybe we'll decide to simply increase the percentage of the bar length later. In any case, it is functional right now and doesn't look bad, so I suggest we don't jump the gun again right now and just deal with it during the upcoming UI reevaluation for this command, when we'll have a bigger picture.

[Suor]

I would say it urgent, 10 char progress bar:

• is ugly
• has limited functionality (poorly shows progress)

So I would say either revert to misaligned ones or put text on top of the bar body and invert text/background color when it is filled.

[efiop]

@Suor

is ugly

Less ugly then it was originally without tqdm. I dont think this one counts as urgent.

has limited functionality (poorly shows progress)

Not really, since it has the right part to it where you get more granular N/M thingy. Again, not urgent.

So I would say either revert to misaligned ones or put text on top of the bar body and invert text/background color when it is filled.

Reverting would be problematic for this one, I would rather not do that. What do you mean by inverting? Not sure I follow that one.

[casperdcl]

I'm assuming inverting means black text on white background where necessary (to have description drawing on top of the bar).

Not sure if there's a reliable cross-platform way to display such a thing. Also wouldn't work well on non-unicode envs which will currently display hashes for the bar.

[shcheklein]

Is there a specific reason to keep so small? Can we do a quick fix to make it 3x wider?

I agree with Ruslan, the whole output might change soon, so I would not put too much effort into fixing this, just a cosmetic minor quick stuff if it's possible.

[casperdcl]

the problem with fixing to say width 30 is increased chance of overflow (on narrow terminals or long descriptions)

[shcheklein]

@casperdcl yeah, totally, I was just assuming probably that we can calculate in advance or tqdm supports this - and specify something like this min(30, number of symbols to the description)

[Suor]

I am against fixed pbars, these look bad.

[Suor]

BTW, the reason behind fixed with bars is several of those dancing when we perform some work in several threads. So if we unite those into one pbar there would no need to bother about fixed size pbars at all.

And now we shouldn't used fixed size pbar outside multithreaded situation.