on Ubuntu libdconf1 depends on libc6 and libglib2.0-0. that's all
BTW while checking dependencies of dconf I came across a `libdconf-qt0`:
Description: dconf Qt bindings (library)
This plugin provides dconf support for Qt applications. The Qt library
shouldn't be used directly as there is no ABI and API stability guarantee.
Homepage: https://gitorious.org/dconf-qt
Can it be helpful?
Regards,
Kuzma
On 29 July 2013 20:54, [email protected] <[email protected]> wrote:
> mandag den 29. juli 2013 skrev PCMan :
>
> On Mon, Jul 29, 2013 at 4:05 AM, Александр Соколов <[email protected]>
>> 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
