Re: [Bug-wget] --progress=dot:giga

2019-06-16 Thread Tim Rühsen
Hi Greg,

I currently can't see that any of us maintainers or contributors will
ever work on this. There is just too much other things to do.

To have a chance, you should add as much details to
https://gitlab.com/gnuwget/wget2/issues/342
as possible.
*IF* you could code an example outside wget, in any language you like,
that would be a great helper. Wget2 has plugin support and we can extend
it to support progress bar implementations - basically in any language.
(Adding command line options via plugin is already functional.)

If this is really an important issue for you, go ahead and be the
driving force behind it. We give you all the help that our time allows.

Regards, Tim

On 15.06.19 18:55, Greg Knittl wrote:
> Hi Tim,
> 
> I would find another column for the wall clock absolute estimated
> completion time useful as I often try to calculate this in my head.
> 
> I think I only care about the dots because they show that the download
> is proceeding normally. Wget already outputs a message if it retries. If
> there is a situation where the download is hanging but wget is not
> restarting it then I think I would prefer a message instead of trying to
> guess what is happening from dots not appearing. With sufficient
> messages in place it would be possible to skip the dots entirely. Or
> instead of dots output a brief message to give download status.
> 
> Whether there are dots or not, let the user select a time or per cent
> complete interval for status updates. I typically pipe wget progress
> output to a file. Usually I don't look at the output at all. In most
> cases it would be sufficient if wget output an initial row after say 1%
> complete and then I could signal wget if I want it to output another
> progress line.
> 
> If wget must have dots then instead of mega and giga options, perhaps
> let the user set the dot size and calibrate the left column units around
> that. If wget allowed per cent complete or time intervals that would set
> the dot size, although not likely to a round number.
> 
> Personally I'm fine with 32 dots per line. I find blocks of 8 easier to
> read (which I usually don't) than blocks of 10. But if anyone cares and
> has time to code it, perhaps an option to specify the dot cluster size
> and clusters per line.
> 
> thanks,
> Greg
> 
> On 2019-06-12 2:58 p.m., Tim Rühsen wrote:
>> Hi Greg,
>>
>> looking at it when downloading a large file, I have to agree.
>>
>> A dynamic multiplier on the left would be nice (K->M->G).
>>
>> I added this as a comment to https://gitlab.com/gnuwget/wget2/issues/342.
>>
>> Thanks for the feedback.
>>
>> Regards, Tim
>>
>> On 12.06.19 06:19, Greg Knittl wrote:
>>> Hi,
>>>
>>> --progress=dot:giga on wget 1.17.1 outputs 32 dots per line where each
>>> dot represents 1MB downloaded.
>>>
>>> The cumulative total at the left of each line is in KB. I would find MB
>>> easier to understand. It matches up with the dots and better matches the
>>> scale of GigaByte files. I still often have download speeds measured in
>>> KB/sec but I don't recall ever comparing download speed to the
>>> cumulative total on the the left.
>>>
>>> I would ask that you at least consider this for wget2. I personally
>>> don't have any programs that read this column of wget output so I would
>>> be fine if it changes in the current wget1 but I would understand if you
>>> consider it an API that you don't want to break.
>>>
>>> thanks,
>>> Greg
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature


Re: [Bug-wget] --progress=dot:giga

2019-06-15 Thread Greg Knittl

Hi Tim,

I would find another column for the wall clock absolute estimated 
completion time useful as I often try to calculate this in my head.


I think I only care about the dots because they show that the download 
is proceeding normally. Wget already outputs a message if it retries. If 
there is a situation where the download is hanging but wget is not 
restarting it then I think I would prefer a message instead of trying to 
guess what is happening from dots not appearing. With sufficient 
messages in place it would be possible to skip the dots entirely. Or 
instead of dots output a brief message to give download status.


Whether there are dots or not, let the user select a time or per cent 
complete interval for status updates. I typically pipe wget progress 
output to a file. Usually I don't look at the output at all. In most 
cases it would be sufficient if wget output an initial row after say 1% 
complete and then I could signal wget if I want it to output another 
progress line.


If wget must have dots then instead of mega and giga options, perhaps 
let the user set the dot size and calibrate the left column units around 
that. If wget allowed per cent complete or time intervals that would set 
the dot size, although not likely to a round number.


Personally I'm fine with 32 dots per line. I find blocks of 8 easier to 
read (which I usually don't) than blocks of 10. But if anyone cares and 
has time to code it, perhaps an option to specify the dot cluster size 
and clusters per line.


thanks,
Greg

On 2019-06-12 2:58 p.m., Tim Rühsen wrote:

Hi Greg,

looking at it when downloading a large file, I have to agree.

A dynamic multiplier on the left would be nice (K->M->G).

I added this as a comment to https://gitlab.com/gnuwget/wget2/issues/342.

Thanks for the feedback.

Regards, Tim

On 12.06.19 06:19, Greg Knittl wrote:

Hi,

--progress=dot:giga on wget 1.17.1 outputs 32 dots per line where each
dot represents 1MB downloaded.

The cumulative total at the left of each line is in KB. I would find MB
easier to understand. It matches up with the dots and better matches the
scale of GigaByte files. I still often have download speeds measured in
KB/sec but I don't recall ever comparing download speed to the
cumulative total on the the left.

I would ask that you at least consider this for wget2. I personally
don't have any programs that read this column of wget output so I would
be fine if it changes in the current wget1 but I would understand if you
consider it an API that you don't want to break.

thanks,
Greg








Re: [Bug-wget] --progress=dot:giga

2019-06-12 Thread Tim Rühsen
Hi Greg,

looking at it when downloading a large file, I have to agree.

A dynamic multiplier on the left would be nice (K->M->G).

I added this as a comment to https://gitlab.com/gnuwget/wget2/issues/342.

Thanks for the feedback.

Regards, Tim

On 12.06.19 06:19, Greg Knittl wrote:
> Hi,
> 
> --progress=dot:giga on wget 1.17.1 outputs 32 dots per line where each
> dot represents 1MB downloaded.
> 
> The cumulative total at the left of each line is in KB. I would find MB
> easier to understand. It matches up with the dots and better matches the
> scale of GigaByte files. I still often have download speeds measured in
> KB/sec but I don't recall ever comparing download speed to the
> cumulative total on the the left.
> 
> I would ask that you at least consider this for wget2. I personally
> don't have any programs that read this column of wget output so I would
> be fine if it changes in the current wget1 but I would understand if you
> consider it an API that you don't want to break.
> 
> thanks,
> Greg
> 



signature.asc
Description: OpenPGP digital signature