glib in kdesupport: yes or no?

[Zack Rusin]

On Sunday 09 March 2003 13:53, George Staikos wrote:
> On Sunday 09 March 2003 13:30, Waldo Bastian wrote:
> > >   You seem to be missing one point though.  wv2 is optional, arts
> > > is not.
> >
> > I am not missing that point. wv2 is an optional component where
> > glib happens to be used because it makes the most sense. I think
> > there will be more places in KDE where a similar decision will make
> > sense and that aren't necaserally optional. I think that a "must
> > use C++" blanket policy for implementations is unnecessary
> > limiting.
>
>    A developer can use whatever he likes, but he must not break other
> code because he chooses to use some new library.  If someone wants to
> link in libraries X,Y,Z, that's totally fine, as long as the code
> gets disabled in the compilation if X,Y,Z are not present.
>
>    In the past we have gone to great lengths to make new libraries
> optional. I see no reason to change this now.

As much as I agree with you as far as the added dependencies go I think 
you're being overly dramatic here. Let's face is GLib is almost on 
every posix compliant machine right now and it's not really such a 
burden to have it installed.
In all comparisons of the size of it everyone mentions that it's only 
few kb smaller than std C++. Make no mistake it's smaller than that. At 
least from my understanding, what Stefan wants is the core glib 
functionality (data structs, portability wrappers, threads abstraction 
and mainloop). That excludes gobject, which brings the total size of 
that library by about 200kb. Also note that stl doesn't provide 
mainloop, which in the case of arts is mandatory.
I support letting KDE developers use GLib but don't/won't support the 
use of GObject. Using GObject is simply unacceptable in any of our core 
components.
One possible solution, besides just agreeing on making glib a dependency 
is to write a wrapper library (bare with me for a sec before going 
"another one?!?!"). Let's call it Unified CLib. Basically it'd be C 
library wrapping all the core functionality shared by projects that 
want to be completely desktop agnostic, that would include basic data 
structs (list, hash, tree), strings wrapper, threads abstraction, some 
portability wrappers and mainloop. The library compiled with Qt support 
would use Qt to do everything, compiled with glib would use glib and 
other projects could add their own implementations, like Enlightenment 
guys with their ECore (look at the threads implementation in DBus to 
see how one wrapps those things). That way we'd have a unified C 
library that would work natively on all desktops, all projects on 
freedesktop.org and other desktop agnostic projects (arts) could use it 
without the overhead of holding their own implementations or 
introducing new dependencies. The main loop integration would be a 
little tricky but doable, the rest of it is trivial. So that would be 
an option if Glib is to be considered unacceptable.
The bottom line is that we can't dictate Stefan what to do with his 
project. If he thinks that using GLib is the best solution then he must 
have strong reasons for doing so. So either we wrap or we adopt GLib, 
it's simple as that, there just isn't a third option that would not 
involve huge code duplication.

Zack

-- 
A program is a device used to convert data into error messages.