GLib/GObject+C as the lingua franca?
thiago at kde.org
Sun Jul 27 18:48:24 BST 2008
>But i'm not really satisfied yet. Don't know how to implement the
>QIODevice::atEnd() and bytesAvailable () functions. GIO is a pull API so
>i can't really "answer" those methods. Perhaps with some read-ahead, but
>then seeking is difficult.
Implement it in sequential mode then, instead of random access:
bytesAvailable() returns the number of bytes you have buffered, the
maximum amount that calling read() can return. In other words, if you try
to read more than bytesAvailable(), you will get bytesAvailable() bytes.
atEnd() = true ←→ bytesAvailable() = 0
>And of course this should work non-blocking - using the GIO-async
>methods. I guess this also needs reading ahead into a buffer, cause
>otherwise i don't know when to emit the QIODevice::readyRead () signal.
True. QIODevice is a push API: you must read as fast as you can from your
lower-level device, unless you fill up your buffer (see
QAbstractSocket::setReadBufferSize) and then emit readyRead() whenever
you get more data.
>Perhaps Qt/GIO bindings should provide both - a QIODevice implementation
>- and a thin wrapper for all the GIO classes: Directory listings,
>file-info, drive/mount management, launching apps, and also the GIO
>streams (maybe useful for the advanced users, dunno).
That makes sense. Those other functionalities aren't streams, so they
don't make sense as QIODevice, clearly. That functionality is also
present in KIO: the directory listings, mount requests, etc., are not
descendants of KIO::TransferJob.
It should be possible to write an abstracted layer of I/O, one that can
use KIO as well as GIO (and even QNetworkAccessManager, but that's a lot
more limited in scope). It could, in the future, replace KIO -- i.e., be
the cleanup of KIO that didn't happen for KDE 4.
As for launching apps... there's klauncher. Or are you talking about
launching applications in a remote host?
>>> Another problem is copy-constructors/operators. Passing around
>>> wrapped GObjects that way works quite nicely, cause you don't need to
>>> care about garbage collection, but Qt Signal connections are lost
>>> when copying the object.
>> Assuming you mean connections of some internal object (since QObjects
>> themselves can't be copied anyway), why not just have this shared
>> object in a shared (reference counted) private?
>Well - actually most of the public KGIO classes can be copied. And they
>do derive from QObject.
That's not possible.
Either they are copiable, or they derive from QObject. Doing both is not
Remember: in the copy constructor and in operator=, you *always* call the
base classes' implementations. And you can't do that with QObject.
I urge you not to try to make QObject-descendant classes copiable. That
would open up for thinking the QObject connections, QPointers, etc., do
transfer, but they can't.
If you want copiable things, use pointers. I'm implementing a generic
pointer-holding class with atomic reference-counting for Qt 4.5, so you
don't have to write anything.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel