Skip to content
Darshit Shah edited this page Sep 24, 2016 · 6 revisions

I started out writing a Bug Report for the broken progress bar, trying to document whatever I've seen. But I figure, a Wiki page is a better location for this.

We already know that the progress bar in Wget2 is broken (so far it is simply a show-case how it could look... maybe some other approach is better !?). However, there seem to be quite a few issues in the code relating to it. I'll try and list them down here, so we can keep striking them off.

Just removed the points that are already done (Tim)

Logging and Errors could go above the current progress bars - not sure if this is possible with ANSI codes. Ncurses could solve the problem, but introduces another dependency + CPU load when starting and not using progress bar at all (Debian tends to non-lazy linking)~~~

233% [=====================================================================>]
     [Files: 2  Bytes: 0  Redirects: 1  Todo: 0                             ]
_We have one bar for each file. The wrong %age is technically correct with respect to uncompressing (gzip Content-Encoding). It just means e.g., Content-Length was 100 but Content-Encoding was gzip and after unpacking the file is 378 bytes long. The uncompressing takes place async to downloading (at the same time). A change in the callback API should allow to display the 'correct' value~~~

Minor Things to implement in the progress bar:

1. Filename marquee _a la_ Wget 1.x
2. ETA computation
3. Handle cases where screen size changes
    1. Stop drawing when width too small
    2. Stop drawing when height too small
    3. Resize according to width and height
4. Change API so client does not set the max size