mandag den 29. juli 2013 skrev PCMan :
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.

What I like about dconf: It's a standard, and it seems to do what we want.
What I don't like: It uses binary storage format. I'm an old and old-fashioned person, and I like to be able to inspect stuff using cat or less. But I guess that's the way the world is turning :-(. 

However, the dconf developers might argue that the binary format is nessecary to get the read-speeds they (and we) want. 

All in all I think we should go the dconf way. 

So how to do it? We would still want to access settings in the code through QSettings, and presumably, when dconf makes it's way into Qt, it will be in the form of a new back-end for QSettings. So if we, for now, create a subclass of QSettings, that replaces reading from files with calls to dconf, we could use that in our applications, and we wouldn't have to change very much once proper Qt-dconf-support is available.

I've had a (very) cursory look at the dconf-api, and I think this is possible.

We could also create a clone of RazorSettings that inherits from this QSettings-subclass (if we keep RazorSettings. I don't know if this is settled)

br. Chr. 

ps. There is one peculiarity: On Arch, where I live, dconf depends on gtk-update-icon-cache. Maybe it's a packaging artifact. Do other distros have the same dependency?