ui factory - what should it do?

[Robert Collins]

On Tue, 2006-02-21 at 17:28 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:

>  
> > So, I'm not at all convinced that passing pbs around in functions
> > 'solves' thread safety issues. Its going to be complex any which way its
> > tackled, and IF that comes up, I'd rather design to address it then.
> 
> But if you have to pass pbs around so that you can create a child
> progress bar, then you are already passing around a progress bar.
>
> Otherwise the ui_factory needs to know whether this call to
> 'ui_factory.progress_bar' is intended as a sub-progress to the current
> one, or a separate process.

Indeed. DRY suggests teaching the factory about that difference IMO. Or
simply saying that each thread is a separate process. Or have an
optional process object that we don't bother using in our code...



> My suggestion for nested progress bars (having used it), is to have each
> progress have a list of children. Then you end up with a tree, which can
> be represented quite well in a GUI, and moderately approximated in text
> mode.

I agree with this.

> Children need to inform their parents when they are done, so that the
> parent can clean them up if it chooses.

I agree with this.

> My feeling is that we either need to pass progress bars around so that
> we can create a tree (or in the simple case just a stack), or we have
> ui_factory just assume that all progresses are either children of
> eachother, or at the same level. If you don't want to expose to callers
> that something slow might be going on deep down, then you have
> difficulty exposing the layering as well.

I think having the ui factory build a stack internally would work well.
We dont have tree like behaviours anywhere for this in the code that I
know of.

> I also prefer passing both a progress bar, and a callback message.
> Because Weave.join() doesn't really care what weave it is working on.
> But at a higher level you care that you are merging inventories right
> now, and that makes a difference versus merging 400 other weaves.
> (Specifically, you would like merging bulk weaves to print out what
> weave it is on, but you would like merging inventory.weave to print out
> what revision it is on).
>
> Maybe this could be taken care of with global debouncing. (So you wait
> to display a new progress for 1 second or so).

Seems to me that passing around the occasional pb where desire fine
grained control is fine. Its the general case that we want to make
seamless. And global debouncing would be nice too.

Also one can imagine a pb.hide_children() call to make the children
noops.

Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060222/55af83ca/attachment.pgp