[rfc] Progress Bar reworking

[Aaron Bentley]

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

John Arbash Meinel wrote:
> After working through the progress bar changes to improve 'fetch', I've
> been thinking that our progress system probably needs another overhaul.
> 
> The primary issue I came across was with multiple locations grabbing a
> top-level progress indicator.

I think any code that does this is broken.  There's no reason not to
grab a nested progress bar.

> Because of UI issues, we really only ever want 2 levels of progress.

I don't think this is correct.  Trying to avoid having more than two
levels would make things harder, and I don't see any gain from doing
that.  More levels of nesting just means we increase in smaller increments.

> The
> current overall (for the whole command, IMO), and then a nested one for
> the current step.

In terms of display, this may be the most helpful approach.

> As another example, I wrote a script which recursively copies a bunch of
> branches. There I have an overall "I'm on branch X of Y", but then a
> narrower "I'm on phase 1/6 for branch 10/20", and then "I'm on revision
> 20/2000 for phase 1/6 for branch 10/20".

I think we can use the existing progress bar stack for doing
arbitrarily-deep displays.

> So I'm trying to figure out what sort of layering would really get us to
> the point that different sub-units can be mixed together in different
> ways. Like pulling into a directory without a working tree won't have a
> "update the working tree" phase. Though we could say that it has a
> really fast one :)

In terms of the API, I don't see anything that needs changing.  For a
tree-less branch, pull shouldn't grab a progress bar.  That will mean
that fetch's nested progress bar will actually be the top-level progress
bar.

For pull-into-tree, there should be two phases, with fetch and pull each
taking one phase.

> I'm thinking that it might make sense to have a ProjectPhase which was
> at the Command level. Or possibly at the UI level. The number of phases
> would be set by the Command, since that could incorporate multiple code
> paths that don't know about each other.

How would this be different from a ProgressPhase?

> 
> Then deeper code could call:
> 
>   bzrlib.ui.ui_factory.next_phase('message')

Why would you want this?  The caller knows when the phases begin and
end.  Doing it here is just begging for trouble.

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

iD8DBQFFbh7Y0F+nu1YWqI0RAjx0AJ9qjeIv/5ajpHm5xFJwpJsJ5OY6fwCffnIG
mQHQTSiii1eDHFzu149KIqM=
=XQTW
-----END PGP SIGNATURE-----