GLib/GObject+C as the lingua franca?
Aaron J. Seigo
aseigo at kde.org
Sun Jul 27 01:55:20 BST 2008
On Saturday 26 July 2008, nf2 wrote:
> Aaron J. Seigo wrote:
> > On Friday 25 July 2008, nf2 wrote:
> >> I wonder if a kind of mixed style would work: libraries with public
> >> GObject/C APIs, but internally stdc++.
> > the phrase "disgustingly ugly" comes to mind.
> Why? I think a lot of things that are tiring with plain C - like
> strings, containers and garbage collection might be a bit easier with a
> bit of C++.
so write in C++ but hobble it with an API designed to make up for C's
shortcomings? that's what i meant by "disgustingly ugly"
> Let's take the KDE desktop environment as an example: Because it's all
> monolithic Qt/C++ the whole infrastructure had to be ported from Qt3 to
> Qt4 as well.
it isn't monolithic anymore, and neither is Qt. nor does Qt have any near term
so if you feel that the Qt3 issues were bad, you're a few years too late to be
complaining about them. Qt4 is a different animal.
> So when you run a KDE3 app on KDE4 you actually have two
> desktop environments running (with all the daemons etc). Good? Or
> wouldn't it be better if "the platform" could move at a slower/different
besides the current state not really mapping to what you describe here all
(look at HAL and it's proposed replacement), we made a lot of decisions to
help make this "slow/different" pace possible.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel