kconfig-elektra

[David Faure]

On mardi 12 novembre 2019 16:58:19 CET kde5 at markus-raab.org wrote:
> Dear KDE developers,
> 
> As discussed in Akademy 2018 [1] Felix Resch and Dardan Haxhimustafa are
> working on a patch for KConfig so that KConfig uses Elektra [2] instead
> of the KConfigINI backend.
> 
> We forked the KConfig repository [3] and currently try to:
> 1. successfully start KDE to use Elektra (Felix Resch)
> 2. implement a new plugin for Elektra that supports the KConfig INI
>    files for a smooth transition to Elektra (Dardan Haxhimustafa)
> 3. improve Elektra's qt-gui, which will provide a low-level GUI for the
>    whole (KDE) configuration (Dardan Haxhimustafa)

Cool.
 
> Two questions came up until now:
> 1. Is KConfigBackend supposed to be thread safe?

No, KSharedConfig::openConfig is thread safe and creates different KConfig 
instances in each thread. This way, KConfig and KConfigBackend don't need to 
be thread-safe.

> 2. If Elektra finds a merge conflict between the KConfig objects and the
>    configuration files on the disc, should we then do a 3-way merge
>    which prefers "ours" or should we ask the user with a KDialog how to
>    proceed?

I'm a bit out of context (2018 was a long time ago), what's the scenario that 
might lead to this happening? It sounds to me like a dialog would bother the 
user with low-level technical things that they won't understand nor know how 
to resolve. If you can describe how this can happen, then we can conclude what 
should be happening automatically to fix the situation.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5