glib in kdesupport: yes or no?

[Waldo Bastian]

On Sunday 09 March 2003 18:56, George Staikos wrote:
> On Sunday 09 March 2003 12:48, Waldo Bastian wrote:
> > On Sunday 09 March 2003 16:08, Neil Stevens wrote:
> > > KDE has used almost exclusively the C++ language since its inception. 
> > > I don't think it's appropriate to try to undermine that choice in this
> > > manner.
> >
> > KDE uses C++ because in most cases that is clearly the superior solution.
> > However, in cases where the advantages of using C outweigh the advantages
> > of C++, the decision has been made to use C. For very much the same
> > reasons it can make sense to use glib instead of C++/Qt/kdelibs. Having
> > such an additional option at ones disposal allows developers to better
> > choose the appropriate technology for the problems that they try to
> > solve. Being able to share code with other development efforts can be an
> > important factor in such decision. See for example the work on wv2.
>
>   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.

> If we have to depend on more libraries for arts, I think arts should be
> made optional too. 

I don't have a strong opinion about arts in particular and I wouldn't mind if 
it were replaced with another solution for those applications that don't 
require arts explicitly.

>  I think it's rediculous to have 3 sets of container libraries.

I think there are worse things to duplicate than a container library. If the 
use of one extra container library can reduce duplications in more complex 
areas then I am all for it.

Cheers,
Waldo
-- 
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com