[RFC] KConfig API stuff

[Andreas Pakulat]

On 22.10.07 02:18:03, Cornelius Schumacher wrote:
> On Sunday 21 October 2007 20:21:56 Andreas Pakulat wrote:
> >
> > What about delaying the release then?
> 
> I don't think that's a good idea. The road to KDE 4 has been long enough. Now 
> we should really concentrate on shipping it. We all will be happier people, 
> once that's done ;-)

I doubt that I'll be happier, but then again I'm don't contribute code
(at the moment) that will be shipped with 4.0 :)

> By the way, there always will be a next release. No need to solve all problems 
> at once.

Except API problems, some of those can't be fixed in the next release.
Unless we break BC and also SC in this case, or live with a deprecated
method that doesn't work on all platforms (and adding the 2 new
functions for KDE 4.1)

> > Quite some time ago (when the 
> > release plans got discussed) it was said that kde wouldn't take the dates
> > as set in stone and delay them if need arises. So which changes would be
> > such a need, if not a finally good KConfig API?
> 
> What's wrong with the KConfig API?

It doesn't allow to write a different backend in a sane way. The most
problematic part for that is AFAIK the entryMap() function, which forces
to return a QString as value.

> It has worked well for many years.

That only means that people got used to its API.

> Sure, there might be some aspects which could be better, but striving
> for perfection isn't necessarily what helps us to get our software to
> our users and that's what we all want, don't we?

Personally I'm not sure I want that :) But as I said, I'm not a major
kdelibs contributor so I won't start that discussion.

> I would say, if the need for a new KConfig API wasn't so pressing in the last 
> two years while we work on KDE 4 that somebody actually did it, it can't be 
> important enough to bring the release in trouble now.

I think its not about pressing need that nobody did it, but more about
quite some code where every change may have weird side-effects. Trying
to understand that beast is a rather huge task. Apart from that the need
arises now that KConfig is not going to be used on only 1 platform and
other platforms already have ways of dealing with user settings that
they want to put "under KConfig".

> > OTOH this could be done 
> > for KDE 4.1 and we could just break the BC with that release.
> 
> If we do that in KDE 4.1 is something we should discuss when we have released 
> 4.0. Right now we should concentrate on finishing the code for the release. 
> Get in release mode.

I personally have the luxury of not doing that, because I don't work on
code thats in release freeze :) 

I do agree there has to be a cut done at some point, thats also why I
think only the removal of KConfigBase (that class doesn't do anything
useful anymore) and the type-change of entryMap should be done. 

> It's much more fun to see things being finished than waiting for the
> perfect API to arrive.

Well, I find it much more fun if something works the first time, than
when it is working perfectly :)

Andreas

-- 
You need no longer worry about the future.  This time tomorrow you'll be dead.