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

[Robey Pointer]

On 15 Feb 2006, at 15:11, John A Meinel wrote:

> Robey Pointer wrote:
>>
>> On 14 Feb 2006, at 17:26, John A Meinel wrote:
>>
>>> 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
>>
>
> Well, it does use the full width of my terminal, which is nice. Though
> if I resize the window, it gets *really* unhappy.

Yeah, it's just using terminal_width() from my previous patch.  To  
cope with window resizing on posix involves catching SIGWINCH and  
having that handler tell any current ProgressBar to change its  
width.  And if you're making the window smaller, you'll still get a  
garbage line.  It ain't curses. :)  (In fact, I'm not sure it's worth  
doing.  Do we really care if a user changes their console window size  
during a bzr operation?)


> Also, why is it that you don't resize the parent back to full width
> after a child has shown up. Is that intentional or accidental? I  
> can see
> a reason for it, I was just wondering what you were thinking.

It disoriented me to have the progress bar grow and shrink a lot, so  
I intentionally forced it to stick with the smaller size once it has  
shown a 2nd bar.  (Otherwise, in the case where you have a top-level  
"update" bar and frequent 2nd-level "get" bars, the "update" bar  
would constantly grow and shrink.)  I think maybe it should even stay  
at the smaller size from start to finish.  Progress bars that change  
size bother me at some level.

robey