From the recent discussions, it seems that dconf will ultimately be the way things will go. Keeping in mind, however, that native dconf support should probably be added into Qt itself.

J. Leclanche


On Mon, Jul 29, 2013 at 3:22 AM, PCMan <pcman.tw@gmail.com> wrote:
On Mon, Jul 29, 2013 at 4:05 AM, Александр Соколов <sokoloff.a@gmail.com> wrote:
> You understood me correctly.
> Yet another one, is a events. Say, when razor-config-panel is changed
> config, razor-panel should to know about this. Now we are using
> QFileSystemWatcher (it use inotify), but this requires some limitations.
> With DBus we can use signals for notifications about changing of the
> settings.

Sriously, if we want:

1. dbus interface
2. dbus activition for the daemon on demand
3. change notifications
4. separated from the session manager

Should we consider dconf?
Dconf provides all of them, and is becoming the de facto standard gradually.
Besides, it's more desktop neutral than creating our own lib.
So other 3rd party programs can use it, too.
It may be difficult to ask 3rd programs to link to our liblxqt or something.
Though I personally prefer plain text config file over dconf, but it
seems that we really need the features it provides.
I discussed this with Jerome quite some time ago, and the conclusion
was we don't touch it for now and keep using QSettings. However,
during our ML discussions, it seems that dbus interface and change
notifications are really wanted. So from existing implementations
dconf is probably a candidate.
If we're going to use it, we should encapsulate it in our own config
class with different backends. One for QSettings, and another for
dconf.
So we don't need to touch implemantation details when using it and
changing backends is possible.

I'd like to have your opinions.