new progress bars only use 80 columns

Hi,

Could you please tell me what 'bzrlib.osutils.terminal_width()' returns? We may be measuring it incorrectly (though that has not changed from previous releases iirc.)

Of the terminal width the specifically "progress bar" bit, as opposed to the other text, is now fixed in size, so that it doesn't jump around and look bad when the text that's displayed grows or shrinks. I think this is still the right approach but maybe it should be fixed to say 20% of the width, rather than the current fixed number of characters.

I'd suggest reserving no more than X characters for metadata/text, and use the rest for the bar.

That makes the textual region predictable, and the bar takes up the slack. In very small terminals the bar can become a single character /|\+ spinner :)

I'd encourage you to consider:

a) getting rid of the progress bar,

b) setting the expectation of 80 chars being the minimum,

c) using a fixed numebr of characers up front for the bandwitdh stuff.

Thus (b) - (c) is known, making it clear to bzr hackers the available width for the most significant characters should be. If they have more to say lovely, but they know they need to make it look good with only (b) - ( c).

AfC

As far as I can tell the current progress view does detect the size of the terminal correctly. If you have a case where it doesn't, please reopen this.

It doesn't respond if the window changes size while bzr is running which is bug 316357.

If you mean that we should use a different allocation of space between the progress bars and the text area, as Andrew and Robert suggest, let me know that's what you mean. I doubt we can please everyone but maybe it can be better.