[MERGE][385191] Use the new progress reporting bzrlib API

Jelmer Vernooij jelmer at samba.org
Mon Jun 15 12:35:37 BST 2009


Vincent Ladeuil wrote:
>>>>>> "Jelmer" == Jelmer Vernooij <jelmer at samba.org> writes:
>>>>>>             
>
>     Jelmer> Vincent Ladeuil wrote:
>     >> 
>     Jelmer> _progress_all_finished shouldn't reset the progress
>     Jelmer> bar widget to None; if the window triggers more
>     Jelmer> progress reports, we shouldn't be displaying those in
>     Jelmer> a window. To reproduce, try hitting "Refresh" in the
>     Jelmer> viz window.
>     >> 
>     >> Right, reproduced, but given that stdout mentions many other
>     >> problems, I think we'd better fix them in another patch :-)
>     >> 
>     >> And I think the right fix here is to re-install the progress
>     >> widget when the refresh button is clicked.
>
>     >> There is still an inherent weakness in the current design
>     >> (already present in the last one, may be worse even): if you
>     >> create a bzr-gtk window with progress widget from a bzr-gtk
>     >> window with a progress widget, which one should show the
>     >> progress ?
>
>     Jelmer> So we would need to re-install the progress widget
>     Jelmer> each time we call out to bzrlib?
>
> That's the idea yes. For bzr viz, it would mean doing it when the
> command starts and when the refresh button is clicked.
>
> In the attached patch, that meant setting the progress widget
> once: in populate(), which makes sense, even if I still think the
> progress widget should be part of BranchWindow instead of
> TreeView.
This needs to happen in a lot more places. Some other calls that can
bring up a progress bar as well (in the case of bzr-git/bzr-svn):

 * opening a branch
 * determining the tags
 * obtaining the nickname
 * getting a revision tree

But the API allows *any* bzrlib function to use progress bars, so in
theory we need this everywhere.

Jelmer



More information about the bzr-gtk mailing list