Elektra backend for KDE

[Avi Alkalay]

Thanks Thiago.

I'll have to think more about it.
This schema sound too much flexible for me, and also seems to be
designed for configuration FILES, and not configuration RESOURCES or
URLs. Is my interpretation right ?

We can interpret FILE paths as RESOURCES paths anyway, but it will
smell like some ad-hoc stuff.

Regards,
Avi

On 2/21/06, Thiago Macieira <thiago at kde.org> wrote:
> Avi Alkalay wrote:
> >I don't know exactly what this means, since I don't know what KDEDIR etc
> > means.
>
> KDEDIR is a deprecated variable. It points to the KDE's installation
> prefix.
>
> KDEHOME is where the user's settings are stored. By default, this is
> $HOME/.kde. The configuration is stored there too, but this is not
> necessary if the backend uses in its own storage.
>
> KDEDIRS, however, is a lot more complicated. It lists the many different
> directories that should be searched for configuration. It defaults to the
> KDE installation prefix. The storage backend MUST allow loading the
> configuration from different trees and merge them in the order they were
> declared in KDEDIRS, respecting the Immutable setting.
>
> This applies to configuration as well as menus and icons (though those two
> are supplanted by XDG_DATA_DIRS). Conceivably, the storage backend could
> use XDG_DATA_DIRS too and we'd be done with KDEDIRS, but this has to be
> upheld.
>
> To add insult to injury, this setting must be done per-application,
> unless /etc/kderc makes the list constant (Kiosk mode). This means that,
> if there is a daemon that handles all requests, this daemon must be told
> the path list that each application expects its settings to be loaded
> from.
>
> >I'm ready to write the backend, but right now I still don't know where
> >to start write it. If it is in the playground code, or in the
> >mainstream one.
>
> Since this is KDE4 code, use branches/work/kde4/playground/libs.
>