On mardi 12 novembre 2019 16:58:19 CET k...@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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
