Adding a storage plugin for xfconf about libelektra HOT 17 CLOSED

Here you go
https://gist.github.com/grindhold/cf784de3faf8ef6c9fbcf1ce1e24e493

from libelektra.

Maybe i should explain my idea a little bit more. My idea is that my tool always talks to elektra.

On KDE, Gnome3, ...
mytool -> libelektra4 -> storage plugin -> simpleini

But on Xfce it would work like this:
mytool -> libelektra4 -> storage plugin -> xfconf

That way Xfce users could use there normal tools to edit the settings.

Greetings
Leo

from libelektra.

Hello, yeah that is the basic idea: tools talk to Elektra and do not have to care where the configuration is stored. Using the CLI command

           kdb mount none /sw/yourtool xfconf

you/the maintainer (via postinst script) or the administrator can choose that the tool's configuration should be stored in xfconf.

Providing a xfconf plugin sounds like a good idea. Via the API libxfconf-0 it should also be relatively easy to implement. The only challenge would be that it seems to not allow rewriting the whole configuration tree. We are also working on gobject bindings, which would allow libxfconf-0 to track all changes to Elektras gobjects themselves. Alternatively, we would have to write synchronisation code ourself, like we already did for the augeas plugin.
I also see some limitations for consistency guarantees (which Elektra supports for all its current plugins), for such a xfconf plugin, because libxfconf-0 supports no transactions. That means when Elektra an another tool start writing into the same configuration tree, the configuration might get messed up (some items from the one source, some from the other)
Directly writing the XML files might be another option without above problems/limitations (if the daemon handles XML file changes correctly).
What do you think?

Anyway thanks for the idea/input!

from libelektra.

Hey,
i am not sure if directly using libxfconf-0-2 is the best way of doing it. Because Xfce4 normaly starts xfsettingsd (http://docs.xfce.org/xfce/xfce4-settings/xfsettingsd) and you directly talk to that daemon. That way they make sure that there are no race conditions if two applications change a value at the same time.

But i am not the best C/C++ guy, so i would propobly aggree with anything you suggest :)
Greetings
Leo

from libelektra.

Hi Leo,

libxfconf seems to talk over dbus with xconfd. Is xfconfd different than xfsettingsd or is it just an old name for the same daemon?

Consistency on single values are sometimes not enough. Elektra guarantees atomic changes over everything the user modified. When the XML files are moved atomically, not only values but the whole content of the XML file would be preserved.

How do you plan to use Elektra in Vala?

best regards,
Markus

from libelektra.

Hey,

libxfconf seems to talk over dbus with xconfd. Is xfconfd different than xfsettingsd or is it just an old name for the same daemon?

i think it's the same think. But i asked the question in the IRC an i am waiting for a response currently.

Here you find a spec for the settings, maybe this helps: http://www.freedesktop.org/wiki/Specifications/xsettings-spec/

How do you plan to use Elektra in Vala?

Currently i am googeling for some already existing vala bindings, but it does not look good. If i don't find some, i propobly have to write them myself. :( (I hate writing bindings )

Greetings
Leo

from libelektra.

Edit: forgett about the link, it's not relevant :(

from libelektra.

Hello,

do the gobject bindings help for Vala?

best regards,
Markus

from libelektra.

Hey,
here is the IRC log from my question:

(06:11:07 PM) leo-unglaub: hey, what is the difference between xfconfd and xfsettingsd?
(06:11:16 PM) leo-unglaub: is xfsettingsd the successor of xfconfd?
(06:34:14 PM) eric_the_idiot: no they do different things, xfconf is a D-Bus-based configuration storage system. xfsettingsd is an application that runs in the background to apply various settings in the desktop, mostly providing http://freedesktop.org/wiki/Specifications/xsettings-spec/
(06:39:27 PM) leo-unglaub: eric_the_idiot: i see, thanks!

Greetings
Leo

from libelektra.

So xfconf is a confstorage and libxfconf-0-2 is a way to access it (next to the xml files) and xfsettingsd is competition to Elektra.

from libelektra.

I added this feature request in the todo list: src/todo/PLUGINS

Please reopen if you have an application using Elektra that actually needs the xfconf.

from libelektra.

heyho @markus2330 ! i chatted you up on vala bindings this afternoon after you talk. it seems that the GI-bindings have been deprecated for some reason. However they are a necessary intermediate step in order to obtain vala bindings. now i am confused. if the GI-bindings aren't here to stay, i probably shouldn't bother generating a VAPI from them.

I already succeeded in generating a VAPI-file from the GI-files generated in master. But now comes the tough part: cleanly integrating it into cmake. Please tell me more about the GI-binding deprecation so i have a understanding whether doing the contribution is worthwile.

from libelektra.

The GI-bindings were only deprecated for python and lua because the SWIG bindings were better (especially performance). There is nothing wrong with them otherwise. There is no plan to remove them. We can relabel them if you have a better word than "deprecated" :-)

The Vala binding would, of course, not be "deprecated"! So it is definitely worthwhile and I would love to see this binding.

from libelektra.

@grindhold any update?

from libelektra.

I could post the manually generated vapi for now, but i did not yet get around to integrate stuff into CMake. I'll post the file in a Gist and paste it here.

from libelektra.

Thank you, that is great!

How did you test it?

Did you try to copy the cmake from the other bindings? (e.g. https://github.com/ElektraInitiative/libelektra/blob/master/src/bindings/gi/lua/CMakeLists.txt)

from libelektra.

The discussion went off-topic. Please reopen new issues if you are interested in a xfconf plugin or open a PR when GI-bindings of Vala are finished (simply copy CMake of other GI-bindings should suffice, adding tests would of course be better).

from libelektra.