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 | [email protected] | 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
