>>>>> "Jelmer" == Jelmer Vernooij <[email protected]> writes:
<snip/>
Jelmer> There can very well be multiple progress tasks, there is no code in
Jelmer> Bazaar to make sure that any top-level call spawns only a single
task as
Jelmer> far as I have seen.
I can't find code that directly create a progress.ProgressTask, hence
they are all created via UIFactory.nested_progress_bar().
Except for test purposes, all pb = nested_progress_bar() calls are
paired with a pb.finished() call (in a finally clause). I.e. even if
they are still called progress bar, they progress tasks, objects which
track progress locally in a function and in all called functions from
there, all called functions creating their local progress task.
>From there, any call to bzrlib will only add ProgressTask objects to the
current UIFactory _task_stack and any progress indication will be
achieved via this current UIFactory.
Jelmer> Any top-level operation can call other methods which in turn
Jelmer> can create individual tasks independent of each other.
No. Well, possibly, but that's not the intent and doesn't fit in the
current model, you'll need to define several UIFactory objects to
achieve that AFAICS. And since there is no need for that so far, I don't
think it's worth discussing that now.
Jelmer> Since this is unlikely to happen, we will need some global
Jelmer> state to keep track of the proper progress bar widget to
Jelmer> use.
>>
>> The current bzr-gtk ui, *tracks* the proper progress widget right now.
>>
Jelmer> No, it loses the proper widget after the first task.
Which my other patch addresses for the only known case.
Note that this other patch is compatible with yours...
<snip/>
Jelmer> We are setting an explicit widget already when we create the
Jelmer> viz window. This patch for me fixes all issues with
Jelmer> progress bars appearing while "bzr viz" is shown.
I understOOd that perfectly :-) Both in intent and in mean.
My "other" patch also fixes all the issues I encountered with bzr viz
(progress bars appearing *AND* warnings related to illegal uses of
GtkIter object).
Hope this helps you understanding the paradigm shift in bzr progress
reporting (and yes, the layering is not correct in bzrlib regarding
transport activity, just have a look at the duplication in qbzr).
Vincent
--
bzr-gtk mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.canonical.com/mailman/listinfo/bzr-gtk
