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

[Robert Collins]

On Wed, 2006-02-15 at 16:17 -0800, Robey Pointer wrote:
> On 15 Feb 2006, at 15:11, John A Meinel wrote:

> 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?)

Yes. I think that the terminal width should be set when bzr starts up
and maintained in bzrlib.ui as a global state variable or perhaps as a
singleton of some sort... Then SIGWINCH changes will be reflected
immediately.

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


Yeah, I put in special machinery to the test-pb stuff I just did to stop
it resizing the [...] bit when the text changed.

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/20060216/389241ac/attachment.pgp