[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Developpement idea, GSOC project ?
From:       todd rme <toddrme2178 () gmail ! com>
Date:       2010-03-28 14:50:00
Message-ID: 6524e4801003280750w5801114dwca5591339c2b0649 () mail ! gmail ! com
[Download RAW message or body]

On Sat, Mar 27, 2010 at 8:12 PM, Thomas Lübking <thomas.luebking@web.de> wrote:
> Am Sunday 28 March 2010 schrieb Romain Couturat:
>> > > but the idea is to integrate directly into KDE.
> you want to use KIO::Job
> http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/classKIO_1_1Job.html


Specifically you want ate least copjob, jobuidelegate, and
renamedialog, all in kio/kio.  coyjob is the most important, while
renamedialog has most or all of the ui's for copyjob (although you
will probably need to make a new class for what you are suggesting).
I've done some work on this recently, and there are several
suggestions I have :

1) non-blocking errors and overwrites: currently if there is an error
or file name conflict it blocks the transfer.  It would be great if
this wasn't the case.  Ideally errors would not block the overwrite
and vice versus, which would probably involve three queues, one for
transfers, one for overwrites, and one for errors.  You also need a
good way to display the errors in the end.  I would say this is the
most important suggestion and one I have seen requested many times.
If you leave a large transfer and go do something else thinking it
will finish there is a very real possibility that a file name conflict
or error will block the transfer entirely.  You shouldn't need to
baby-sit transfers like that.

2) single transfer queue.  Currently each transfer operation has its
own queue, which means if you start 5 copy jobs you will have 5
queues.  This should probably be changed so that they all share the
same queue, but whether to put, say, transfers from different kio
slaves in the same queue will need to be worked out by you and your
mentors.

3) number of parallel downloads.  Setting how many transfers should be
done in each queue simultaneously.  Once again there are details you
will need to work out.

4) work out a good way to open the queue.  Transfers are currently
displayed in KDE in the plasma notification system.  When that is not
available, they are displayed in a window.  You will need a way to
open the queue from both.

5) set retries.  It would be nice if we could set it to retry failed
transfers a certain number of times before giving up.

-Todd
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]