Elektra backend for KDE

Avi Alkalay avi at alkalay.net
Mon Feb 20 18:16:53 GMT 2006

On 2/20/06, Thomas Braxton <brax108 at cox.net> wrote:
> So that looks like KConfig's Keys and Groups, but a file can have
> unlimited
> groups. Is this possible with Elektra? If not, then we might have to come
> up
> with a different interface. Or elektra might treat the KeySet
> "systems/sw/xorg" as the file, and all KeySets immediately under that as
> the
> groups of that file. KConfig right now only has a very simple idea of
> nesting, there is no nesting of groups, so it only does:
> file
>   group1
>     keys
>   group2
>     keys
> there isn't a way to have
> file
>   group1
>     group2
>       keys
>   group3
>     keys
> So Elektra group/key names might end up looking like directories, ie
> KConfig kc("systems/sw/xorg");
> kc.setGroup("InputDevices");
> kc.readEntry("Mouse0/Options/Device");
> or
> kc.setGroup("InputDevices/Mouse0/Options");
> kc.readEntry("Device");
> should probably return the same thing.

KDE current configuration schemas are 2 dimensional only, so you'll heve
only keys under groups under a configuration resource like konquerorrc.
Currently you don't have groups under groups under groups. Elektra allows
that, and maybe your new interface and classes will allow that.

So an elektrified KConfig can be like this:

KConfig ks("konquerorrc");  // The backend will translate it into

and on multilevel configurations, like X.org:

KConfig ks("xorg");  // The backend will translate it into

See, Elektra can provide to KDE to be capability to manage not only KDE's or
desktop applications, but access to any other system's function
configuration, because Elektra was designed to be systemwide.

This very X.org example is real, since we already wrote a patch for X.org to
read config from Elektra, and not from /etc/X11/xorg.conf. We did it too for
/sbin/init's inittab, fstab, then we'll patch Samba, and maybe Apache too.
Having an Elektra backend, KDE can manage any elektrified system software,
simply by using KConfig's classes.

How you mark things as immutable will be backend specific. ini does it by
> adding a tag "[$i]" to the end of the groups/keys that are immutable, or a
> group named "[$i]" to mark the file as immutable.

Yes, I was thinking something exactly like this.

So where are a source tarballs I can download to start playing ?

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

More information about the kde-core-devel mailing list