GLib/GObject+C as the lingua franca? (was: kwallet and QCA)
nf2 at scheinwelt.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)
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.
> 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