kconfig-elektra

[kde5 at markus-raab.org]

Dear David,

Am 16.11.19 um 03:20 schrieb 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.

Perfect, then we can directly have Elektra's KDB handle within our
implementation of KConfigBackend.

>> 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),

I am not even sure if we even discussed this at all.

> what's the scenario that might lead to this happening?

Someone presses "save" in a configuration dialog but this change would
overwrite another change in the configuration file done by another
process (e.g. another application (instance), some CM tool, manual
modification of the INI file, ...).

Steps to reproduce such an issue:
1. Start the application, let us assume this is the only point in time
   where the application reads the configuration.
2. Modify the INI file of the application externally.
3. Press save in the configuration dialog of the application.

> 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.

In the case the person had manually edited the INI file (or used Elektra
to modify the configuration) him/herself, he/she would understand. If
some other tool changed the INI file, it would be exactly as you say.

> If you can describe how this can happen, then we can conclude what 
> should be happening automatically to fix the situation.

Unfortunately, we cannot know if the "other change" happened by the user
him/herself or by some script the user is not aware of.

The current situation is that *all* changes some other process did are
lost. In Elektra and automatic 3-way merging in favor of "ours", you
will only lose changes in which there are actually conflicts. So it will
already be an improvement -- even without a dialog. If you do not want
to lose *any* changes, an interaction is needed (like "git merge" has).

best regards,
Markus