[Development] QSettings refactor updates

[Milian Wolff]

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
> principles.
> 
> 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 
settings.

Bye

-- 
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