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

[nf2]

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

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.

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.

Cheers,
Norbert