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
signature.asc
Description: This is a digitally signed message part.
