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

List:       calligra-devel
Subject:    Re: Calligra 3.0 for Qt 5.1?
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2013-07-30 11:23:33
Message-ID: alpine.LNX.2.00.1307301315080.3543 () calcifer ! valdyas ! org
[Download RAW message or body]

On Tue, 30 Jul 2013, Jos van den Oever wrote:

> The KIODevice : public QIODevice would have to have an async implementation 
> like QTcpSocket and QProcess. No rocket science, but something to keep in 
> mind. waitForReadyRead() and waitForBytesWritten() would be needed to block 
> until KIO::FileJob gives back data.

For calligra, I think that sychronous would be quite okay -- and I think 
that even just using local files would be quite okay. In fact, I am sure 
that there quite a few places where non-local KIO file handling was 
broken.

>
> Perhaps KF already has an adaptor that returns a QIODevice from a 
> KIO::FileJob.
>
> Do we need more KIO than simply
>  FileJob *KIO::open(const KUrl &url, QIODevice::OpenMode mode)
> ?
>

Well, we use KIO in 218 places in 93 files --

KIO::NetAccess::del
KIO::move
KIO::NetAccess::synchronousRun
KIO::move
KIO::storedHttpPost
KIO::copy
KIO::NetAccess::download
KIO::NetAccess::exists
KIO::NetAccess::stat
KIO::NetAccess::removeTempFile
KIO::NetAccess::upload
KIO::file_copy
KIO::filePreview
KIO::PreviewJob::availablePlugins()
KIO::storedGet
KIO::moveAs

Seems to be the sum of the KIO api we use -- plus what's hidden inside 
KFileDialog and so on.

Boud


_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
[prev in list] [next in list] [prev in thread] [next in thread]