HttpDownloader::downloadProgressRange/value should be qint64

[GoogleCodeExporter]

As int can't hold big sizes (e.g. 3GB), in a download progress we should use 
qint64 instead of int.
See 
http://stackoverflow.com/questions/4931780/how-to-nicely-cast-qint64-to-int-for-
qprogressbar for this.

Percent is no solution either, as a progressbar size of > 500 makes the steps 
>5px, this is not smooth.

Solution:
progressbar->setRange(4096);
progressbar->setValue(bytesRead/bytesTotal*4096);

Original issue reported on code.google.com by christian.a.reiter@gmail.com on 11 Dec 2012 at 9:05

[GoogleCodeExporter]

Or we can send either percentage (prog*100/total) or 10.000 (prog*10000/total)

Original comment by eric.mae...@gmail.com on 11 Dec 2012 at 9:22

[GoogleCodeExporter]

See comment: 
http://stackoverflow.com/questions/4931780/how-to-nicely-cast-qint64-to-int-for-
qprogressbar#comment5498423_4931806

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 9:39

[GoogleCodeExporter]

in reality, the HttpDownloader needs no downloadProgressRangeChanged(qint64, 
qint64) signal, as the "range" never changes. Only the total bytes change, and 
the range always is 0..totalbytes.

So HttpDownloader could have 2 signals:
void bytesRead(qint64)
void bytesTotal(qint64)

range + percent are not really needed...

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 11:49

[GoogleCodeExporter]

QNetworkReply has only a signal downloadProgress( qint64 bytesReceived, qint64 
bytesTotal )

This is the really only signal we need, and we are more compatible with Qt.

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 12:58

[GoogleCodeExporter]

1. Nop we should provide precomputed score...
2. if you download multiple files range changes min && max, that's why we 
should keep both
3. also provide simple interface, with more specialized objects. We are not 
coding Qt but FreeMedForms :D

Original comment by eric.mae...@gmail.com on 11 Dec 2012 at 1:14

[GoogleCodeExporter]

but the range "min" never changes, right? it's always 0.
One httpdownloader can only download 1 file, right? so when downloading 5 files 
simultaneously, wen'd have to use 2 httpdownloaders and calculate the sum 
ourselves in the dialog!

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 1:17

[GoogleCodeExporter]

min can change is you resume a download. (min>=0)
avoid to duplicate code in multiple dialogs. What you will code in your own 
dialog must be also coded in all other part that uses HttpDownloader. This is 
not "coding easier"?

Original comment by eric.mae...@gmail.com on 11 Dec 2012 at 2:15

[GoogleCodeExporter]

> So precomputed range/value
> 0 -> 10000 and value is int

Hm. this solves the progressbar smoothness, but allows no way to add a "12345 
of 1863789 bytes downloaded" string.
Hm. What about using the downloadProgress(qint64, qint64) for normal Qt 
compatibility, and the normal percent  for convenience?
Anyone who wants %, doesn't care about smoothness. Anyone who wants data (exact 
byes etc), needs the first one.

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 8:30

[GoogleCodeExporter]

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 8:39

• Changed state: Started

[GoogleCodeExporter]

Ok, suggestion:

    void downloadProgress(qint64 bytesReceived, qint64 bytesTotal);
    void downloadProgressPermill(int);

BTW: the starting range point is never needed: even when you resume a download 
at the half, 0 is the starting point, and totalBytes the end; the downloaded 
bytes are set then as bytesReceived, so that the progressbar is at the middle 
and you can optically see that half of the file is already there.

The only thing I can think of someeone needs a starting point >0 is when you 
want to have input values from e.g. 32 to 64, and want to set dem directly 
without subtracting 32 of every int, so you can directly use setRange(32,64) 
instead of (0,32) and setvalue(x-32). It's just for convenience, but 
downloading files ALWAYS stars at 0.
Would the two signals above be ok for you?

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 8:47

[GoogleCodeExporter]

Ok, even if really don't understand why you want to remove signals as they are 
not heavy code and can be helpfull is some situations.
Don't forget to manage FTB && FMF, both use this code.

Original comment by eric.mae...@gmail.com on 11 Dec 2012 at 9:52

[GoogleCodeExporter]

Hm, I don't really want  to remove signals if they are needen and good.
I was just struggling how we could get two things under one hat:
1. the downloading progress of the HttpDownloader: qint64 type
2. the normal progress of e.g. FTB/IFullReleaseStep etc, you use mostly 
range(0,1..3) there.
I don't really want to change it to MY solution, I just had/have problems with 
the current and don't know wxactly how to solve them... ;-)

Fact is: you NEVER use the range min >0 in FMF/FTB/any. so this is redundant 
info...
If we removed it, we could use just one signal for range and progress.

To recapitulate it:
the main problem is that QProgressBar is not capable of qint64 which is needed 
by downloads.
all other occurrances  (FTB, etc) could use the current scheme, even if the 0 
min is  useless IMHO.

So what we could do is implement a wrapper slot that translates 
downloadProgress(qint64 bytesReceived, qint64 bytesTotal) into 2 signals: 
progress(int) and downloadProgressRangeChanged(int,int), which we can use for 
progressbars directly.

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 10:18

[GoogleCodeExporter]

" So what we could do is implement a wrapper slot that translates 
downloadProgress(qint64 bytesReceived, qint64 bytesTotal) into 2 signals: 
progress(int) and downloadProgressRangeChanged(int,int), which we can use for 
progressbars directly. " -> Humm this is already coded...

What's wrong is the percentage -> permile for the uis and the DownloadStatus.
May be a management of multi-download can be added later.

Code your patch, send it, we will have a better idea of the problem/solution.

Original comment by eric.mae...@gmail.com on 11 Dec 2012 at 10:33

[GoogleCodeExporter]

Permille is absolutely ok for me in that context.
I'll code and push. 
Thanks for ya patience ;-)

Original comment by christian.a.reiter@gmail.com on 11 Dec 2012 at 10:58

[GoogleCodeExporter]

Original comment by eric.mae...@gmail.com on 21 Jan 2013 at 7:58

• Changed state: Fixed