On Mon, Jul 29, 2013 at 5:24 PM, Kuzma Shapran <[email protected]> wrote: > 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?
I believe that it's a packaging artifact. What gtk-update-icon-cache does is simple. It reads all image files in the specified icon theme, decompresses them, and then writes the output to a single binary cache file. Then, the binary cache can be used in gtk+ via mmap. In that way, every gtk+ programs using the icon theme share the memory usage of icons because it's a mmaped cache, hence reduce memory usage. Qt does not support this cache, though. So, it really has nothing to do with dconf. ------------------------------------------------------------------------------ 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
