ui factory - what should it do?

[Robey Pointer]

Cool that this came up again.  I was about to try plugging in the new  
textui progress bar to see how it would work -- I'll hold off. :)


On 21 Feb 2006, at 15:41, Robert Collins wrote:

> On Tue, 2006-02-21 at 17:28 -0600, John Arbash Meinel wrote:
>>
>> 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.

The only way I can imagine needing a tree is if we have multiple  
threads working simultaneously (each wanting to show a pbar of their  
own progress).  If that's true, then a stack in the factory won't cut  
it: the parent pbar will need to be passed down to each child.


>
>> 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.

... So that's good news. :)


>> 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.

The code I posted last week used a single pbar object, on which  
callers could push and pop state.  Debouncing is trivial that way.   
We could also use weakref to do an automatic pop when a child pbar is  
collected (though I may be jumping ahead here).

robey