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

List:       kde-devel
Subject:    Re: Developpement idea, GSOC project ?
From:       Jonas_Bähr <jonas.baehr () web ! de>
Date:       2010-03-29 19:28:20
Message-ID: D5271BFB-DABA-4E77-838D-5577FBA237B0 () web ! de
[Download RAW message or body]


Am 28.03.2010 um 16:50 schrieb todd rme:

> 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.

Regarding the queue you could also take a look at Krusader (extragear/ 
utils) which provides a feature like that: http://www.krusader.org/handbook/basic.html#queue

>
> 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 <<

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

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