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

[Darshit Shah]

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

pgpDQrxYoQjBv.pgp
Description: PGP signature