GLib/GObject+C as the lingua franca?
nf2 at scheinwelt.at
Sun Jul 27 16:33:16 BST 2008
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)
>> \ /
>> 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:
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
> 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.
More information about the kde-core-devel