bug-wget
[Top][All Lists]
Advanced

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

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


From: Tim Ruehsen
Subject: Re: [Bug-wget] [RFC] Reverse scrolling direction
Date: Thu, 04 Dec 2014 12:57:38 +0100
User-agent: KMail/4.14.2 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )

On Thursday 04 December 2014 16:55:40 Darshit Shah wrote:
> 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.

Ok, good point. Such a use case needs indeed the filename printed.
When you have implemented 3. above, maybe we can agree upon
--progress=bar:noscroll as default ?

Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

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