[rfc] Progress Bar reworking

[John Arbash Meinel]

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.

The fetch code uses a ProgressPhase to indicate that it has 4 (6 after
my work) phases before it is complete. After my rework, I could get this
to work fairly well. Such that the size of each phase was reasonable
relative to the amount of work to be done, and the next layer down could
give reasonable information about what was going on.
However, it turns out that after doing the fetch, we then update the
working tree, which itself has another ProgressPhase, completely
unrelated to the first.

Because of UI issues, we really only ever want 2 levels of progress. The
current overall (for the whole command, IMO), and then a nested one for
the current step. It might be possible to have more nested ones, but the
basic premise is that you really should have a global view of what is
going on.

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

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


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.

Then deeper code could call:

  bzrlib.ui.ui_factory.next_phase('message')

This shouldn't cause any errors if it overflows the number of phases.
Though I think we should have an env flag that could do so, to help
developers track down how many phases different commands go through.
Certainly we could always mutter() how many phases we have done.

My other concern, though, is that sometimes the number of phases might
depend on what format is used underneath. (weaves have a slightly
different number of steps for fetching than knits).

I don't really want to have to write the code around progress bars, but
I'm not sure how to do a good job otherwise.

Thoughts?

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061129/1f484861/attachment.pgp