[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: GLib/GObject+C as the lingua franca? (was: kwallet and QCA)
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: 2008-07-25 16:47:38
Message-ID: 200807251847.44696.kevin.krammer () gmx ! at
[Download RAW message or body]
On Friday 25 July 2008, nf2 wrote:
> 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...
Probably the same requirements for the other way around, i.e. Qt being built
with GLib mainloop support and a QEventLoop object.
> 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.
> 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?
> 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.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic