[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:       "koos vriezen" <koos.vriezen () gmail ! com>
Date:       2008-07-25 20:51:05
Message-ID: d4e708d60807251351w6d26b5afjc76f8c045258df69 () mail ! gmail ! com
[Download RAW message or body]

2008/7/25 Stefan Teleman <stefan.teleman@gmail.com>:
> On Fri, Jul 25, 2008 at 3:42 PM, koos vriezen <koos.vriezen@gmail.com> wrote:
>
>> 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.
>> Btw. Vala is a nice alternative to get a nice OO language w/o extra
>> dependencies (for as long as it takes of course)
>
> Yes, and duplicating already existing work -- especially when backed
> by the "too many symbols in shared library" argument --  is *always*
> the best alternative. Even more so when said existing work does have

I don't understand. Why is that argument special?

> some successful history of being maintained, and being used in other
> applications.

Well, maybe I missed the point and is it about nice API for end
application developers. My impression though was syntactic (yes no
synthetic :) sugar for the GIO <-> KIO layer. In which I wonder how
many hack on this anyhow. So the best alternative IMO is not to wrap.

Koos
>
> --Stefan
>
> --
> Stefan Teleman
> KDE e.V.
> stefan.teleman@gmail.com
>
[prev in list] [next in list] [prev in thread] [next in thread]