Vincent Ladeuil wrote: >>>>>> "Jelmer" == Jelmer Vernooij <[email protected]> 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 -- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
