glib in kdesupport: yes or no?

[Waldo Bastian]

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 suggest that developers shouldn't have that choice and that they 
should always be using C++. I think that's irrational.

> > I think you try to say "lowest-common-denominator" but I don't see any
> > support for that opinion. I don't see how the use of glib would lower
> > any aspect of KDE, in fact I think it would only improve KDE in certain
> > areas: Those area's where now homegrown C-based solutions are used. If
> > part of those solutions could be replaced with glib functionality it
> > would be an improvement because the more common glib functionality has
> > most likely received more testing and there are more people already
> > familar with glib making maintenance easier.
>
> C *is* the lowest common denominator of C and C++.  Stefan acknowledges
> that repeatedly, yet he advocates that KDE use more C.
>
> glib is an inferior (see Stefan's comments on gobject) substitute for Qt,
> yet Stefan suggests that KDE adopt it:

Your reasoning is solely based on gross generalisation. In most cases C++/Qt 
is superior to C/glib, however that doesn't rule out that in _some_ cases 
C/glib is a better choice. In those cases KDE should use it.

> > I think that the adoption of glib for certain tasks within KDE will make
> > it easier to achieve such consistency.
>
> KDE was founded for UI and behavioral consistency, yes.   Can you explain
> to me how the use of glib in KDE will influence GNOME UI to obey KDE
> standards?
>
> We can't very well gain consistency by disobeying our own standards, so
> GNOME adoption of KDE standards is the only way to get more consistency.

We can promote the adoption of existing and upcoming KDE standards by offering 
other projects an implementation of those standards or even by jointly 
developing such implementations in a way that they are acceptable for 
inclusion in those projects. 

Epecially in areas where the KDE standards are more de facto standards rather 
than documented standards, this can be very helpfull to improve consistency. 
I am not so much thinking in terms of visual appearance here, but more in 
terms of behaviour, e.g. the opening of a browser to open a URL, the 
sound-server to use to play a sound.

glib can be helpfull there by providing commonly needed functionality without 
repeatedly duplicating that functionality (which you would need to do if you 
didn't use glib or Qt) and without introducing rather large dependencies 
(C++/Qt is a much larger dependency than C/glib). As such I think that glib 
can offer the right balance in those situations.

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