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

[koos vriezen]

2008/7/25 koos vriezen <koos.vriezen at gmail.com>:
> 2008/7/25 Stefan Teleman <stefan.teleman at gmail.com>:
>> On Fri, Jul 25, 2008 at 1:08 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
>>
>>> the same can be done with other frameworks. glib isn't magical in this regard.
>>
>> http://www.gtkmm.org/download.shtml
>>
>> GLib-2 and Gtk+-2 already have C++ wrappers (and so do pango, atk and cairo).
>>
>> My question is: instead of to writing OO in C (which has been fondly
>> described by some as "putting makeup on a pig: the pig doesn't enjoy
>> it, and the end result is frightening" :-), wouldn't it be more
>> efficient to use the already existing C++ wrappers ?
>
> No, because when we need something that uses another toolkit to play
> nicely in KDE, the dependencies should be as small as possible. Just a
> quick example:
> $ nm -D /usr/lib/libgtkmm-2.4.so.1.0.30 |grep ' T ' |wc -l
> 8932
> $ nm -D /usr/lib/libgtk-x11-2.0.so |grep ' T ' |wc -l
> 3535
> so almost a triple extra symbols to resolve at load time.
>
> Maybe some 'use Qt for every job' may dislike gtk or plain C in
> general, but a. they either have no clue what happening beneath it
> and/or b. are too stubborn to look over their horizon anyhow. Others
> will pick up the job.

Oops, this sounds a bit to harsh I guess. With 'no clue' I meant 'no
clue or interests'. We all have our thing, whether it's GUI, databases
or system programming.
The point I wanted to make is that putting synthetic sugar over lower
level API's makes only things slower, while a pure GUI developer
doesn't maintain this code anyhow. For the one who does, wrappers
probably more confuse than help.

Koos

> Btw. Vala is a nice alternative to get a nice OO language w/o extra
> dependencies (for as long as it takes of course)
>
> Koos
>
>
>> Just my  0.02 question.
>>
>> --Stefan
>>
>> --
>> Stefan Teleman
>> KDE e.V.
>> stefan.teleman at gmail.com
>>
>