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

[Andreas Pakulat]

On 01.03.07 12:54:28, David Faure wrote:
> On Thursday 01 March 2007, Paolo Capriotti wrote:
> > On 2/28/07, Stephan Kulow <coolo at kde.org> wrote:
> > >
> > > I don't think we want two ways to stores settings in kdecore.
> > 
> > Yesterday I've refactored Settings to be backend-based, a backend
> > being a couple of template instantiations which implement the
> > serialization and deserialization logic.
> > The next step (I'll tackle it this evening if I have time) is to
> > implement a KConfig backend. This way my class would act as a wrapper
> > for the KConfig framework, and provide the additional features, like
> > subgrouping, arrays and maps, plus the more convenient syntax, with no
> > change in existing configuration files.
> 
> 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.

On a side note: Why does KConfig not use QSettings (at least under the
hood)? If there's some docs that explain the reasons please point me to
them, I'm just curious...

Andreas

-- 
Alimony and bribes will engage a large share of your wealth.