glib in kdesupport: yes or no?

[Neil Stevens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday March 09, 2003 11:38, Zack Rusin wrote:
> 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.

GNOME is part of POSIX now?

I think KDE has wider distribution than GNOME, does it not?  If wide 
distribution ist he metric, then glib should be ditched in favor of Qt.

> 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.

That's not the issue.  The questions are:  Should the copies of glib 
classes be replaced with a hard glib requirement?  Should glib be put into 
kdesupport?

At least, I haven't seen anyone tell Stefan to go rewrite aRts to use Qt 
yet. :-)

> 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.

This isn't about letting people use glib.  This is about *requiring* glib 
for even a minimal KDE install.  If aRts requires glib, then everyone has 
to mess with it (which is why I say it should be in kdesupport if it's 
required).

> 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. 

Why is the burden on C++ coders to appease C coders?  I'm with George.  
Let's educate, not coddle.

> 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.

Well, by putting his code in the KDE release, Stefan did agree to abide by 
KDE policies.  This is what Daniel Duley and everyone else has gotten 
told.  So yes, to a point, KDE can tell Stefan not to require glib.

In the worst case, we can fork.  The popular theory is that aRts is barely 
maintained anyway.

Not that I advocate that.  I'd be satisfied to see glib in kdesupport.  No 
hassles.

- -- 
Neil Stevens - neil at qualityassistant.com
"Among the many misdeeds of the British rule in India, history will
look upon the act depriving a whole nation of arms as the blackest."
 -- Gandhi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+a5ogf7mnligQOmERArj2AJ0RWHzikrB2rfsbggWPUeHfMMUMdQCcDRF1
1xQawtGAWYmkCJO12ao7MNM=
=DvB8
-----END PGP SIGNATURE-----