[RFC] KConfigBase v KConfig

[Thomas Braxton]

On Friday 04 November 2005 08:56 am, Thiago Macieira wrote:
> I don't see why any application developer should know that the config file
> is an INI-style file or hardcode that information into his program. We
> may decide, in the future, to exchange backends (TDB, for instance).
>
> So, we should have a front-end class for config (called KConfig) and
> backend classes (plural) for the various backends we have, starting with
> INI (called it KConfigINIBackend, for instance).
That's why I think we should be using the interface class and not the 
implementation class, but most of the code in KDE uses the implementation 
class unnecessarily.

If we don't change the names of the classes, most of the code in KDE should be 
changed to use KConfigBase(interface) instead of KConfig(implementation). If 
we do change the names then the few valid uses of KConfig, opening a file, 
would have to be changed to KConfigINI.

The reason I think we need KConfig/KConfigINI separation is portability. Now 
that Qt4 is more cross-platform, we could make it easier for programs to fit 
in with the "native" desktop. With KDE on Windows, are they going to use 
KDE's way or are they going to use the Windows registry, or something else 
entirely. Also, what about KDE programs on a Mac? I don't even know how OSX 
deals with preferences, or even if they have a standard way. If we keep 
KConfig as a base then it will only matter where they have to open a 
file/registry/whatever.