[MERGE] no-flicker progress bars

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ellerman wrote:
> On Tue, 2006-06-20 at 23:54 -0400, Aaron Bentley wrote:
>> When I implemented overall
>> progress, I wanted to make sure the bar was constant-width, and that was
>> the only way that came to mind.
> 
> Cool, I'm not fussed about constant width, although I guess you don't
> want it jumping around too much.

I think the right answer to that is to set the text width in advance,
and truncate anything that doesn't fit.

> 
>> What would you think of this?
>>
>>
>> \ [==========                ] fetch revision 234 of 563 (33% overall)
> 
> I'd like that a lot.
> 
> I'm not sure how that would work for 1-step operations though, like
> grabbing the inventory knit, where it's either not done or done. But I
> think it'd still be an improvement, even if just for the revision
> fetching stage.

We actually have something similar for single-phase progress.  By
memory, it's

/ [======================] fetching revisions 50 of 100 50%

But that was meant for multi-phase stuff, and might only be used for that.

> The whole phase idea is a bit whack IMHO, in that for fetch we have four
> phases, the relative durations of which are completely unknown, and yet
> they occupy an equal amount of space on the progress bar.

Sure.  This is the kind of thing I mean by 'we're still feeling our way
around'.  All we know is what not to do.

People were pretty clear with us that they didn't like having a whole
bunch of progress bars whiz by, and never knowing how many to expect, or
what the overall progress was.  Doing phases was the answer I came up
with at the time.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEmMoW0F+nu1YWqI0RAhlsAJ9rGABtFoacCvYQSD/bbpt2iDD2ZgCfeXGa
04s0LUbfGzsEMKCea+Q1ja4=
=MWca
-----END PGP SIGNATURE-----