[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [RFC] Reverse scrolling direction

From: Darshit Shah
Subject: Re: [Bug-wget] [RFC] Reverse scrolling direction
Date: Thu, 4 Dec 2014 16:55:40 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

On 12/04, Tim Rühsen wrote:
On Tuesday 02 December 2014 17:52:48 Darshit Shah wrote:
On 11/27, Darshit Shah wrote:
>A couple of days ago, Giuseppe suggested (on IRC) that maybe we should
>reverse the direction in which the filename in the progressbar
>His reasoning was that the last part of the file is the most important
>for most people / use cases. This use case is recursive retrieval
>where once you're a couple levels deep, actually knowing the filename
>could be difficult with the current scrolling mechanism.
>I've attached a patch which reverses the direction of the scrolling.
>The patch is currently only a proof of concept and will be changed and
>cleaned for the final version. However, I'd like everyone's views on
>the direction of scrolling and how it looks reversed. I believe that
>after reversing it, the progress bar may be more useful in a recursive
>retrieval, but looks a lot worse.
>My suggestion is to add another option to the --progress=bar switch,
>something like this:
>--progress-bar:rtol and --progress=bar:ltor for switching between the
>two scrolling styles, with rtol (Right to Left) being the default.

Any updates / suggestions / reviews on this topic?

Hi Darshit,

currently with -r I see something like this

Saving to: ‘www.hostname.d.de/lkdfsldkflsdf/subdir/xxx/file-to-save’

www.hostname.d.de/lkdfsldkflsdf/subdir/xxx/file-       [ <=>                    
                                                  ]  77.81K  --.-KB/s   in 0.1s

My personal favor would be
1. IMHO, for single-threaded downloads we don't need the filename in the 'bar' 
line at all.
That is true. However, when it comes to parallel downloads, we will want to see the filename in the progress bar. The current progress bar is meant to be used directly in the parallel downloads case, which is why I implemented it early.

2. but if a user wants it: just print the filename into the 'bar' line (I can 
read the 'Saving to:' line pretty well).
This is implemented as the --progress=bar:noscroll option

3. if the plain filename name is too long, I would like to see the beginning 
and the and with ... in between without scrollling.

I like this approach when not scrolling. I'll look into implementing this.

However, even when using single-threaded downloads, let me elaborate on a use case for such a progress bar.

Gentoo by default uses Wget to download ebuilds for package management. A lot of Arch Linux users also tend to use Wget instead of the internal downloader to download their packages for use with pacman. Now, verbose mode prints too much data to the screen along with the progress bar. The --no-verbose mode does not print the progress bar, and neither does the --quiet mode.

Hence, I added the --show-progress option to Wget. Now users who wish to download multiple files together, can use the `-q --show-progress` switches and get *only* the progress bar output to the screen. In such a scenario, the filename *must* be available in the progress bar.

This kind of output is also valuable to to people trying recursive downloads who simply want to keep a tab on the files being downloaded but not all the additional data that Wget seems to always provide.

Thanking You,
Darshit Shah

Attachment: pgpDQrxYoQjBv.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]