GLib/GObject+C as the lingua franca? (was: kwallet and QCA)

nf2 nf2 at
Fri Jul 25 14:17:14 BST 2008

Robert Knight wrote:
>> For historic reasons KIO and 
>> KWallet landed in this "KDE desktop environment"
> Those 'historic reasons' presumably include the licensing issue that Qt is GPL - which,
> as I understand it, would not be acceptable for gnome.  If Nokia were prepared to re-license the non-GUI
> components of Qt (eg. QtCore, QtNetwork) more permissively that might change.  

Even then i don't know if QtCore based libraries would work in-process 
outside Qt based applications. I guess you need to instantiate 
QCoreApplication for the event loop etc...

> One alternative is writing the code with glib (using their type system) and then writing a C++ wrapper
> which provides a Qt/KDE style interface to give a consistent feel for KDE programmers.  

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

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 

The third problem i got is thread-safe unregistering C-callback-handlers 
(which emit the QSignals). But for the moment i don't care, as the async 
operations will most likely be used from the main-thread only.

> Unfortunately 
> that means:
> 1)  Writing more code in the first place because glib/C is less efficient that Qt in terms of features/lines-of-code

Fortunately a lot of code already exists, but for new things i agree.

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 
API's probably makes sense for language bindings (AFAIK lot's of them 
can be auto-generated), C is still the lowest common denominator, 
abstract interfaces can be modeled with GInterfaces easily (like GIO 
does a lot) ...

> 2)  Writing lots of glue code between the two layers, which will have some performance hit.

I guess mostly it won't matter a lot - only if a method is called really 
often (and doesn't do "slow" things like IPC internally anyway). QString 
to char* conversion in getters and setters has some performance hit 
maybe... And of course symbol tables are becoming a little bit fatter.


More information about the kde-core-devel mailing list