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 ? So we would need to re-install the progress widget each time we call out to bzrlib? Right now nothing else installs a progress indicator, so this isn't really a problem (yet). > Jelmer> Other than this, this patch seems good enough to > Jelmer> land. We can always fix the minor issues later, right > Jelmer> now this not landing breaks bzr-gtk in general. > > Exactly and it seems that several users were already blocked. > > So I landed the patch as is. I really think the Refresh issue should've been addressed, it's a regression for users currently on bzr < 1.16. Or perhaps we should've just disabled progress bar support completely for bzr >= 1.16 for the time being. Cheers, Jelmer -- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
