[Development] QSettings refactor updates
milian.wolff at kdab.com
Mon Oct 13 15:06:38 CEST 2014
On Monday 13 October 2014 14:41:08 Thiago Macieira wrote:
> On Monday 13 October 2014 13:47:44 André Somers wrote:
> > Thiago Macieira schreef op 11-10-2014 10:25:
> > > On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote:
> > >> I tougth about having a changed() signal on the QConfig / QConfigGroup
> > >> classes, is the QConfigWatcher a better approach?
> > >
> > > Put it in a separate class. QConfig (Group) should not be a QObject.
> > Why not?
> QConfigGroup definitely cannot be a QObject. QObjects can't be copied, so we
> can't do the value semantics we asked for. Those are conflicting design
> Make it like the QDBusPendingReply + QDBusPendingCallWatcher or QFuture +
> QFutureWatcher pairs. We have the precedent there.
Exactly. And also keep the other branch of this thread in mind: QConfig
is/should be a low-level fundamental building-block for a "high-level"
settings API. KConfig XT and KConfig have the same/similar connection.
The high-level settings API could/should have signals, properties,
getters/setters etc. pp. The low-level API is used internally to read/write
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
More information about the Development