GLib/GObject+C as the lingua franca?

[nf2]

Kevin Krammer wrote:
> On Friday 25 July 2008, nf2 wrote:
>   
>   
>> Yeah - i am currently playing with Qt/C++ bindings for the GIO API to
>> investigate this. It's a bit tricky, particularly with interfaces,
>> multiple inheritance... For instance this case:
>>
>>    WrappedObject (carries the GObject)
>>
>> InputSteam    Seekable(Interface)
>>     \                  /
>>     FileInputStream
>>
>> I tried to solve this by deriving from WrappedObject with the virtual
>> keyword, but i don't know whether this is good or evil. ;-)
>>     
>
> Not sure if you actually have to do all this, e.g. streams, having a GIO data 
> source/sink as a QIODevice will most likely be enough.
>   

I already got a simple QIODevice implementation called "FileDevice" 
which wraps FileInputStream.

Here is an example:

http://websvn.kde.org/trunk/playground/libs/kommodity/samples/kgio-iodevice-sample.cpp

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.

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.

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

>   
>> 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.


>   
>> I wonder if a kind of mixed style would work: libraries with public
>> GObject/C APIs, but internally stdc++. Staying with GObject/C for the
>>     
>
> I think TagLib and libpoppler are examples of C++ based libraries which are 
> used in GLib based applications, so they could probably serve as an example 
> how the GLib Wrapper is done for programmers using C.
>
>
>   

Thanks for the hint. I'll have a look.

Cheers,
Norbert