--32u276st3Jlj2kUU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 09, 2003 at 09:42:22AM +0100, Stefan Westerfeld wrote:
> I am not sure whether I should put glib-2.0 in kdesupport, basically,
> because I am not sure what the platforms KDE developers use are. Under
> most linux distributions, glib-2.0 should be available as package.
> However, under some other systems, glib-2.0 might not be packaged (i.e.
> windows, AIX).

I'm using KDE in a semi-embedded project where a couple of hundred extra k's
would not be welcome. Personally I'd welcome a small Arts Lite, which merges
streams and nothing more, for desktop use, drop-in replacable with Arts
Advanced, with every feature possible. Then I would not care if Arts
Advanced would depend on glib.

It has long been argued that most of the arts features are overkill for a
desktop environment anyway. Then again, I remember previous discussions
about this and I believe there were some convincing arguments against 'esd'
as well.

> I'd propose not adding it, because glib is part of the GNOME project. At =
this
> point in time, I see no distinction between KDE and GNOME any longer.

> And if you still think KDE and GNOME are seperate projects, and for that
> reason don't want to install glib-2.0 on your system, I think you're keep=
ing
> up the illusion that KDE and GNOME are working on different goals. They a=
re
> not. Thus, this is no valid reason for me.

It seems to be a valid reason to plenty of people.

Anyway, if KDE starts to depend on glib, I'll put monopd in kdegames adding
a dependency on libmath++ and libcapsinetwork to KDE(-games) as well, just
to make a point. I know, monopd isn't geared towards KDE (the reason it's
seperate from Atlantik is to specifically allow a broader adoption), but
neither is arts, so that's no valid reason for me.

My opinion is that any code in KDE CVS (except qt-copy and kdesupport)
should be specifically geared towards KDE. If arts is not, it should not be
developed inside KDE CVS, regardless of whether we use it.

KDE has a very moderate amount of required dependencies and I'd like to keep
it that way unless we adopt a policy to change that. But if there's any way
there can be a lightweight arts to be included and an advanced one as
drop-in add-on replacement, that'll make me happy.

Rob
--=20
Rob Kaper     | "They that can give up essential liberty to obtain a little
cap@capsi.com | temporary safety deserve neither liberty nor safety."
www.capsi.com | - Benjamin Franklin, Historical Review of Pennsylvania, 1759

--32u276st3Jlj2kUU
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+baDhtppIl2G1SjcRAiT/AJ9pn2V6jWLtj0lfwIXUbooUn+9qLgCfQniZ
39S2/KfFNPnJB+1efuOQvYM=
=vh83
-----END PGP SIGNATURE-----

--32u276st3Jlj2kUU--