GLib/GObject+C as the lingua franca?

[Thiago Macieira]

nf2 wrote:
>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 
possible.

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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080727/d03a82d4/attachment.sig>