mandag den 29. juli 2013 skrev PCMan :
> On Mon, Jul 29, 2013 at 4:05 AM, Александр Соколов
> <[email protected]<javascript:;>>
> 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?
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list
