>>>>> "Jelmer" == Jelmer Vernooij <jel...@samba.org> writes:
<snip/>
Jelmer> This needs to happen in a lot more places. Some other calls
Jelmer> that can bring up a progress bar as well (in the case of
Jelmer> bzr-git/bzr-svn):
Jelmer> * opening a branch
Jelmer> * determining the tags
Jelmer> * obtaining the nickname
Jelmer> * getting a revision tree
Haaaa, but that's an entirely different family of bugs you're raising
there ! Moreover those ones were present *before* my patch and now I
understand why I couldn't reproduce them.
Jelmer> But the API allows *any* bzrlib function to use progress
Jelmer> bars, so in theory we need this everywhere.
Right, a different approach is needed there....
I don't think we can safely define several UIFactory objects (one for
each main window say, and even there making sure such windows are
realized (in Gtk speak) before any bzrlib function is called).
That leaves an implementation where each top-level window defines its
own progress report widget and install it as soon as it get the focus ?
Not suitable for all focus policies... ugly too.
Right, multiple calls to set_progress_widget doesn't hurt, but now I can
see why we don't want to call it with None in _finished. Yet, that's the
only way to get some coherence in progress report: all explicit calls
should set their adequate progress widget.
And top-level windows should call it when they are destroyed (or you risk
having calls to the progress widget after its destruction). Hence you
end up with the same problem, only at a different time: you may find
cases where no more progress widgets are available and you had to use a
progress window.
There should be more rare though.
Vincent
--
bzr-gtk mailing list
bzr-gtk@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.canonical.com/mailman/listinfo/bzr-gtk
