ui factory - what should it do?

[John Arbash Meinel]

Martin Pool wrote:
> On 22 Feb 2006, Robert Collins <robertc at robertcollins.net> wrote:
>> On Wed, 2006-02-22 at 14:53 +1100, Martin Pool wrote:
>>> On Tue, 2006-02-21 at 17:05 -0800, Robey Pointer wrote:
>>>
>>>> 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).
>>> Probably better to just have code use a try/finally block in the scope
>>> where the progressbar is created.
>> What about progress bars in objects?
>>
>> I.e. Fetcher.
>>
>> I suppose we need to ensure theres a very clear 'active lifetime' for
>> such things so that a finally can be written.
> 
> In that particular case it's clearly working for only the duration of
> __init__.  (Which is perhaps not an ideal idiom; other job-type classes
> have an explicit "do it" method, and perhaps we should standardize
> that.)
> 
> If we had a class that hung around for a long time, with no clear scope
> for when it was acting, and that wanted to keep updating a progress bar,
> then I don't think it would fit into a stack setup at all.
> 

Agreed. But if a class hangs around for a long time, and doesn't have a
scope for when it is acting, then it doesn't really deserve a progress
bar either, as it has no sense of 'when I will be done'.

Otherwise, it should just create a pb when it *is* acting.

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060221/a3459d94/attachment.pgp