[MERGE] no-flicker progress bars

[Martin Pool]

On 21 Jun 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> > 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%

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...)

> 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.

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"

 - 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"

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

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 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.

-- 
Martin