glib in kdesupport: yes or no?
bastian at kde.org
Sun Mar 9 18:30:45 GMT 2003
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
> 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.
bastian at kde.org -=|[ SuSE, The Linux Desktop Experts ]|=- bastian at suse.com
More information about the kde-core-devel