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

[Paolo Capriotti]

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. 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.
- 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.
- Adds arrays and maps. I find these very useful. Arrays are similar
to the corresponding feature of QSettings. Maps are a new thing :)

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.
Backend-enabled Settings seemed like a good compromise :)

I understand your perplexity in replacing KConfig, but I invite you to
give a try to my library (http://kboard.sourceforge.net/settings) and
help me find a way to integrate its features in KConfig, if what I've
proposed doesn't seem feasible.

Thanks,

Paolo