KConfig vs. QSettings (was Re: Porting problems with KMainWindow::readProperties())

[David Faure]

On Thursday 01 March 2007, Paolo Capriotti wrote:
> On 3/1/07, David Faure <faure at kde.org> wrote:
> > KConfig is supposed to be the one with multiple backends.
> > I don't think we want an extra layer on top of kconfig - we have so much code using
> > the kconfig api already. And I do mean a lot.
> >
> > I would much rather see an extra mechanism in kconfig for nested groups,
> > like the mechanism suggested by Andreas Pakulat.
> 
> Yes, David, that's exactly the reason I've started with the Settings
> thing in the first place.
> I was thinking that this extra mechanism could come in the form of a
> layer on top of KConfig. 

Sorry, when I said 'extra mechanism' I meant: a new mechanism within the KConfig API,
not an extra layer with a whole different API.

> This has IMHO some benefits: 
> - Avoids touching KConfig, which as you said, is used by a lot of
> existing code, so we'd better not break it.
I disagree. Better add a feature that makes it possible to use nested groups
-without- having to port all the existing code to a new api for config usage.

> - Improves the syntax. This cannot be done so easily inside KConfig.
> Well... the fact that the syntax is better is a matter of taste, but
> it is surely more compact and doesn't have function names like
> readFontEntry which in my opinion are a bit against the c++ way of
> handling types.
We don't have readFontEntry anymore in kde4, it's all handled via QVariant now.
Well at least we don't have readBoolEntry etc anymore.

> - Adds arrays and maps. I find these very useful. Arrays are similar
> to the corresponding feature of QSettings. Maps are a new thing :)
I see no reason why kconfig couldn't get that feature too, especially now that
it all goes via QVariant, which supports lists and maps.

> Anyway, I need nested groups and the other extra features for my
> project (that was the motivation for rolling my own config class), but
> I would also like to conform to the KDE way of doing things.
The KDE way of doing things is to take into account the porting effort when
changing APIs :)

> Backend-enabled Settings seemed like a good compromise :)
I disagree. Backend-enabled KConfig is what we already have (at least there's
some design for that and some work happening in the direction of more backends).
But the issue here isn't about backends, but about the public API.

> I understand your perplexity in replacing KConfig, but I invite you to
> give a try to my library (http://kboard.sourceforge.net/settings) 
It might be the best thing since sliced bread, that wouldn't change the fact that
I completely oppose porting all the kde code to a new config class (we are just
out of a massive and painful port to KConfigGroup), and I would also oppose
two apis for the same goal within kdelibs. Which leaves only one solution: adding 
the missing features to KConfig. If it wasn't feasible at all it wouldn't be a solution,
but from what I read in this thread it seems possible.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).