glib in kdesupport: yes or no?
zack at kde.org
Sun Mar 9 19:38:10 GMT 2003
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
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.
A program is a device used to convert data into error messages.
More information about the kde-core-devel