[Development] QSettings refactor updates

Oswald Buddenhagen oswald.buddenhagen at theqtcompany.com
Fri Oct 10 13:21:22 CEST 2014


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.

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.



More information about the Development mailing list