[pacman-dev] Broken pacman output when resizing
Hi there! As probably everyone noticed one time or the other, pacman output (in particular progress bars) breaks whenever one resizes the terminal, which leads to scrambled output like this: https://paste.xinu.at/LNo/plain This is due to the fact, that pacman always claims the whole terminal width. Whenever one runs pacman in tmux (split pane) or uses a tiling wm, resizing happens quite often and will produce such broken output. Considering the output closely, we have quite some "uninteresting" information there. All the 100% progress bars are actually redundant as pacman does not continue installation (or download) if it cannot retrieve a package. Also, it only downloads one package at a time, so we only really care about the progress of the last package (or total progress). I thus propose a different output: https://paste.xinu.at/m-5XEa/ version1 uses a fixed 100 columns output, version2 a fixed 80 columns output. In version1 it is possible to draw the per package progress at the same line as the package name. When complete, only the package name remains. In both versions the currently downloaded package is always the last line of the output. Both proposals contain an example for per package and total progress. I'm personally in favour of version2, because it seems safe to assume that we always have 80 cols available and it also unifies the output style for both per package and total progress. To sum up the changes shown in the mockups, I propose: * progress bars of database synchronising, download and installation move on line below compared with the current output * when a step is complete, the line with the package (or step) name remains, but without any width-dependent progress bars. For download, you find and example in the link above. For installation a finished steop could look like this: (26/63) upgrading opus So basically just the redundant progress bar is removed here. * The output is limited to 80 columns which should fit nicely as seen in the example. * Other output (such as warnings, errors, new optional deps, ...) remains the same. Is there any interest for such a change? If so, I could develop and provide a patch. I'm also happy about comments, fine-tuning and further improvements to the proposal. -- Constantin
On Sun, 29 Nov 2015 13:14:46 +0100 Constantin Weißer
version1 uses a fixed 100 columns output, version2 a fixed 80 columns output.
Why do you force it to be 80 chars wide? How about simply limiting it to 80 chars?
-> [254.5 MiB] ↓7.49M/s 01:00 [######--------------] 36%
The whitespace after the time seems totally unnecessary. Sure, it's in line with the version where you display the total percentage, but a user is never going to see both at once so why bother? Just get rid of the whitespace and either use a fixed length for the progress bar or start after the time and fill it up to 80. I'm in favour of pinning the length to 20 chars though because I feel like this gives enough visual indication of progress. This will result in the progress bar being at different positions all the time, but if the user only ever sees one this does not matter. Apart from that I like the idea. I don't see any value in having the output cluttered with 100% progress bars.
On 29/11, Florian Pritz wrote:
but a user is never going to see both at once
I've actually wanted to see both on quite a few occasions when I've had either big updates or a very slow connection. -- Sincerely, Johannes Löthberg PGP Key ID: 0x50FB9B273A9D0BB5 https://theos.kyriasis.com/~kyrias/
On 29/11/15 22:14, Constantin Weißer wrote:
Hi there!
As probably everyone noticed one time or the other, pacman output (in particular progress bars) breaks whenever one resizes the terminal, which leads to scrambled output like this:
https://paste.xinu.at/LNo/plain
This is due to the fact, that pacman always claims the whole terminal width. Whenever one runs pacman in tmux (split pane) or uses a tiling wm, resizing happens quite often and will produce such broken output.
Considering the output closely, we have quite some "uninteresting" information there. All the 100% progress bars are actually redundant as pacman does not continue installation (or download) if it cannot retrieve a package. Also, it only downloads one package at a time, so we only really care about the progress of the last package (or total progress). I thus propose a different output:
version1 uses a fixed 100 columns output, version2 a fixed 80 columns output. In version1 it is possible to draw the per package progress at the same line as the package name. When complete, only the package name remains. In both versions the currently downloaded package is always the last line of the output. Both proposals contain an example for per package and total progress. I'm personally in favour of version2, because it seems safe to assume that we always have 80 cols available and it also unifies the output style for both per package and total progress.
To sum up the changes shown in the mockups, I propose:
* progress bars of database synchronising, download and installation move on line below compared with the current output * when a step is complete, the line with the package (or step) name remains, but without any width-dependent progress bars. For download, you find and example in the link above. For installation a finished steop could look like this:
(26/63) upgrading opus
So basically just the redundant progress bar is removed here.
* The output is limited to 80 columns which should fit nicely as seen in the example. * Other output (such as warnings, errors, new optional deps, ...) remains the same.
Is there any interest for such a change? If so, I could develop and provide a patch. I'm also happy about comments, fine-tuning and further improvements to the proposal.
Pacman's output only goes weird if the terminal width is made smaller, and even then only sometimes. My guess is there is a race condition between the time the width is calculated and when the output is printed. If the terminal is shrunk in that time, the output goes over two lines and on the next update only the second line is overridden. How do you intend to stop this? While your example looks fine, you will still get partial progress bars everywhere in the output when the terminal shrinks. Also, we need to consider parallel downloads (this will happen in the future). A
Firstly, I agree with Florian's points, i.e. limit to 80 rather than fix to 80 cols, such that the output does not break if the terminal is smaller than 80 columns and removing the additinoal whitespace. Quoting Allan McRae (2015-11-29 14:04:16)
Pacman's output only goes weird if the terminal width is made smaller, and even then only sometimes. My guess is there is a race condition between the time the width is calculated and when the output is printed. If the terminal is shrunk in that time, the output goes over two lines and on the next update only the second line is overridden.
How do you intend to stop this? While your example looks fine, you will still get partial progress bars everywhere in the output when the terminal shrinks.
So I think there are really two issues at hand here. One is the "old" progress bars which are all full at 100% and in the lines above the one that is currently updated by pacman. Those are never redrawn and they become ugly (producing linebreaks) when the terminal width is reduced. My proposal was to remove those, as they provide zero information to the user. This should be a small patch. The other thing is the currently drawn/updated progress bar which is resized and realigned by pacman if the terminal width changes _while_ the progress bar still changes. Now in this matter I have — honestly — not much experience. I'm just going to try to explain my point of understanding: If we limit the width of the whole line to 80 columns (including some status info and the bar) and we assume that the user never downsizes the terminal below 80 columns, does that potential race condition even matter? pacman would only really care for the actual terminal width, if it was below 80, otherwise it would just draw 80 columns tops and hence procude clean output in any terminal size. I'm not quite sure, but if this race condition exists it might be quite difficult (or impossible) to deal with it in a clean way. Assuming that all terminals are usually >80 cols could be an okay trade-off.
Also, we need to consider parallel downloads (this will happen in the future).
Very well. I assume the number of parallel jobs is arbitrary but not too big, so my recommendation is, for 4 parallel downloads: jdk8-openjdk-8.u66-1-x86_64 gtk-update-icon-cache-3.18.5-1-x86_64 gtk3-3.18.5-1-x86_64 kded-5.16.0-1-x86_64 kdesu-5.16.0-1-x86_64 kjsembed-5.16.0-1-x86_64 knotifyconfig-5.16.0-1-x86_64 kpeople-5.16.0-1-x86_64 kross-5.16.0-1-x86_64 plasma-framework-5.16.0-1-x86_64 threadweaver-5.16.0-1-x86_64 krunner-5.16.0-1-x86_64 kxmlrpcclient-5.16.0-1-x86_64 openal-1.17.0-1-x86_64 [#######-------------] 26% oxygen-icons-1:5.16.0-1-any [#-------------------] 01% texlive-bin-2015.37497-5-x86_64 [###################-] 94% texlive-core-2015.38835-1-any [###-----------------] 16% where the bottom four lines are updated by pacman while the lines above never change further. If the texlive-bin is done before any of the above, it is appended to the end of the completed list and this line is not updated again subsequently. Again, we can argue about the whitespace after the package name, although I really think it looks nicer when aligned in this case. (I left out speed and ETA for the sake of my laziness. I hope you can imagine those.) -- Constantin
On 11/29/15 at 01:14pm, Constantin Weißer wrote:
Hi there!
As probably everyone noticed one time or the other, pacman output (in particular progress bars) breaks whenever one resizes the terminal, which leads to scrambled output like this:
If you just want to narrow pacman's output, you can use the COLUMNS environment variable: COLUMNS=80 pacman -Ss foo apg
participants (6)
-
Allan McRae
-
Andrew Gregory
-
Constantin Weißer
-
Florian Pritz
-
i7c＠posteo.de
-
Johannes Löthberg