Elektra backend for KDE

Avi Alkalay avi at alkalay.net
Mon Feb 20 16:57:10 GMT 2006

On 2/20/06, Thomas Braxton <brax108 at cox.net> wrote:
> On Monday 20 February 2006 09:45, Avi Alkalay wrote:
> > Thomas, how far is this new API from being accepted in the official
> source
> > ?
> At the moment, it is only me and Aaron working on it, but if we want to
> implement any other backends for KDE4, then something like this will have
> to
> be done, because the current KConfigBase/KConfig assume entirely too much
> about the file format.

When we started to rethink Elektra with multiple backends, a lot in the
interfaces had to change to acomodate a more generical approach. This is
normal and you only have the chance to make it right when you have the
chance to use many different technologies.

> As a side note, on Elektra there are no config files. So maybe this
> methods
> > should be renamed to something like retrieveConfigResource() and
> > saveConfigResource().
> > A filename can be a configuration root, etc, so we can use them the way
> > they are today anyway.
> Would these "resources" be a group of key/value pairs? If yes, then I
> don't
> see a problem with renaming the functions. If not, then what would they
> be?

Your current interface would fit, though the method names only don't make
much sense. Thats a minor issue.

On elektra we have Keys and KeySets. A Key (and its value) is something like

system/sw/xorg/InputDevices/Mouse0/Options/Device: /dev/input/mice

While a KeySet can be all keys under system/sw/xorg
Check here for more examples:

So the idea for the backend is to map Elektra Keys and KeySets to KConfig's
keys. Then we have to solve how to make kiosk, etc.

Or download the very-graphical-presentation I made in KDE's event in
Ludwigsburg in 2004:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060220/0588968b/attachment.htm>

More information about the kde-core-devel mailing list