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
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
