Vincent Ladeuil wrote: > <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. > The situation I'm talking about is where we finish the first progress bar before creating the next. There is no guarantee that we always create only one top-level progress task for each function call in bzrlib.
In fact, bzr-svn and bzr-git can display progress bars from deep inside Branch.last_revision() because that function call can be quite slow the first time it is called. > 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. > This seems to imply there should always be a top-level progress bar? Perhaps we should always make sure there is a top-level progress bar created before we do an operation in bzr-gtk? That way that's the only progress bar and your original code that reset the progress bar widget after the top-level task was finished should work ok. > 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. > For the only case that happens to happen with the branch/repository format that you are using. Other formats may do completely different things and display more or fewer progress bars. > <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). > The GtkIter changes are fine, but I'd like to discuss the progress bar problems further first. Cheers, jelmer -- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
