[MERGE] no-flicker progress bars

[Aaron Bentley]

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

Martin Pool wrote:
> On 21 Jun 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> I think I saw you recently remove the time prediction from the default
> constructor, which I think is good because it was very approximate, and
> the user can judge approximately by themselves.  (Although I don't
> remember seeming them recently...)

I think they were accidentally removed some time ago when throttle was
updated such that self.start_time was always None.  I just made it explicit.

> To speak in terms of goals rather than mechanism I would like this:
> 
>  - there is some text displayed that is meaningful to a user
>    with a bit of understanding of the underlying model - e.g. "pushing
>    revisions" rather than "fetch phase"

Agreed.

>  - similarly, the numbers displayed should be related to the real number
>    of objects being accessed - if i'm pushing 8 revisions that touch 14
>    files I want to see "/8" or "/14" not always "/4"

Okay, but caveat: I don't want to reduce other progress indicators to
that granularity.

>  - it's fine for operations like comparing the revision history or 
>    opening the branch to just say "comparing histories..." with no 
>    numbers

I'm not sure what the distinction would be here.  Comparing histories
would involve downloading a certain number of revisions.

> Having an overall non-decreasing progress bar is nice but I don't think
> it's critical.  Typical operations will have just one slow phase

I can't agree.  For merge, phases 1-3 can have similar durations, and
which phase is slowest will depend on the circumstances of the merge.
Target branch repository type, source branch latency, and checkout
filesystem speed each have an effect on a different merge phase.

 I think giving users an idea of what stage we're at is more than
"nice", I think it's important.  Overall progress bars per se are not
required, but I think something is.

> and if
> users are accustomed to seeing "pushing revisions" take most of the time
> they'll be fine.  What *is* harmful is when it keeps appparently
> repeating the same operation with different numbers.

I think it is hard to avoid repeating the same message for different
phases, because different phases will inevitably use the same underlying
routines some of the time.

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

iD8DBQFEmXVT0F+nu1YWqI0RAtnUAJ4y/l4UQ8X4U+R4N6JUIUxA302bDACfTIKj
+aerrstpvfok6rGbRJ/WKD8=
=41Fe
-----END PGP SIGNATURE-----