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
