Calligra 3.0 for Qt 5.1?

[Jos van den Oever]

On 07/30/13 10:39, Cyrille Berger wrote:
> On 2013-07-30 00:01, Friedrich W. H. Kossebau wrote:
>>> And make the OSX port finally not suck. And make Android ports that
>>> aren't a
>>> hack possible. And yes, I want those Windows users, too. They are
>>> important.
>>
>> You should have all that with KF5 as well, so far the plan. And with
>> Qt5.2
>> even better than with Qt 5.1
>> (D-Bus or the embedded filedialog might be a problem, right, but the
>> stuff
>> which depends on/uses it can be turned into code variants/plugins, so
>> it can
>> be still provided on those platform where it is native, like the
>> Gnu/Linux
>> ones)
>
> That is what I was also thinking for KIO, which is probably the biggest
> piece we are gonna miss with KDE integration. It could be solved by
> implementing an abstraction layer for file system access. Something like:
>
> class IOAccess
> {
> public:
>    QIODevice openReadStream(const QUrl& _url);
>    QIODevice openWriteStream(const QUrl& _url);
> };
>
> And then have two implementations, one for KIO (used on Linux) and one
> using QFile. I guess this might be moved in the future to KF, as I guess
> many more KDE Applications who wants portability don't really care about
> all the features of KIO's API, and just want to read files.

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.

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

Cheers,
Jos