[Development] QSettings refactor updates

[Milian Wolff]

On Friday 10 October 2014 13:21:22 Oswald Buddenhagen wrote:
> On Fri, Oct 10, 2014 at 11:26:52AM +0200, Milian Wolff wrote:
> > On Friday 10 October 2014 11:18:38 Oswald Buddenhagen wrote:
> > > On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote:
> > > > may I ask why you don't simply copy KConfig? It's API design has
> > > > proven to be extremely versatile and efficient over the years.
> > > 
> > > actually, it has proven horrible and is slated for a rewrite for a
> > > decade. the only thing it does right is what tomaz copied to his api.
> > 
> > To my knowledge, only the internals are horrible and could easily be
> > improved, speed wise.
> 
> the api is also horrible. it's full of inconsistencies. it has some
> specifics that make a clean multi-backend implementation not fully
> feasible. the c'tor flags for cascading and other features are rather
> error-prone. also, the duality of KConfig vs. KSharedConfig makes no
> sense.

There are some dark corners in the API - that is correct. But you usually 
don't have to care about that. The API that one uses normally is pretty good 
and definitely better than having to manually use references or such. That's 
what I have in mind when I talk about the good API of KConfig :)

> on a different matter, what do we do about config change notifications?
> i tend to a separate class, say:
> 
>   QConfigWatcher::QConfigWatcher(const QConfigGroup &group);
>   Q_SIGNAL changed(const QString &key);
> 
> then we can postpone the actual design and implementation.

Yeah, I like that idea, similar to what one can do via KSettings::Dispatcher, 
just nicer.

Bye
-- 
Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin

Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions