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