random thought of the day - a progress bar for tree transforms ?

[Robey Pointer]

On 14 Feb 2006, at 17:26, John A Meinel wrote:

> Robey Pointer wrote:
>>
>> I played with nested progress bars this morning, but didn't like  
>> the way
>> they looked.  My kinda half-baked idea was that child progress bars
>> would just operate a spinner inside the parent, like this:
>>
>> [=====/          ] copy  109/8743
>>
>> Subdividing the parent would be useless, since in my experience, the
>> parent is usually iterating over thousands of items.  But the spinner
>> coming and going just looked confusing.  Anyone got better ideas?
>
> This is the code I wrote for layout. It doesn't include how you  
> actually
> set the items, but anyway.
>
> This gives progress bars that look like:
>
> |====    | parent  50% |====== | child  80%
>
> We could add more information like the count, and time till finished,
> but there is only so much room on one line.

I like this.  I find the count pretty useless compared to the percent- 
done, and kinda ambivalent about ETA anyway.  I ran with your example  
and tweaked it a bit: I increased it to 3 spaces between graphs (to  
help separate them visually).  Also I fixed an off-by-one for the  
unlikely case that the message is longer than the width and added a  
unit test for that.

Then I mocked up a ProgressBar class that can have new state pushed  
on & popped off.  I've attached it -- if you run the script, it  
should do a short demo of a two-stage progress bar.

My concept here was that, given that two progress bars are really as  
much visual noise as we want to display, then only show the original  
top-level pbar, and whatever the "current" latest one is.

Anyway, curious if this is worth any further tinkering.

robey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pbar.py
Type: text/x-python-script
Size: 8125 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060215/761f2c58/attachment.bin