Slows starting of downloading with KIO

[Andras Mantia]

On Monday 19 December 2005 19:49, David Faure wrote:
> If we didn't stat the files, we wouldn't be able to know that they
> are files and not directories (which would need a recursive listing).
> And if we wait until an error like "this is a dir and not a file" to
> do that, then we can't provide meaningful progress information - what
> initially looks like copying 4 "files" (urls) ends up being "copying
> 3 files and then copying a huge directory full of files", so
> allocating 25% of the progress to the latter phase would be wrong.
I see, but is it worth to have an accurate progress information and slow 
operation? OK, might be a rhetorical question for a GUI tool, but maybe 
it can be optimized or a compromise found between accurate feedback and 
fast operation. I will think about it.

> If you know those URLs are always files, then you can use
> KIO::file_copy to copy them (but in that case there's no overall
> progress info provided by KIO, since each FileCopyJob is about one
> file).
But this is about using Konqueror as a file manager or Krusader ...
Just try to copy for example the *patch.rpm files from
ftp://mirrors.kernel.org/pub/suse/x86_64/update/10.0/rpm/x86_64

(if you have an unlimited internet connection).

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051219/2be0a31f/attachment.sig>