[RFC] KConfigBase v KConfig

[Thiago Macieira]

Thomas Braxton wrote:
>> Maybe rename
>>  - KConfigBase -> KConfig
>>  - KConfig -> KFileConfig
>> as that's what it is supposed to be imo. Then KConfig could be used
>> for all arguments.
>
>KConfig should probably be renamed KConfigINI, the backend is called
>KConfigINIBackend.
>
>> Only problem is the *lot of* work to do it, also very confusing if a
>> class suddenly does something else. otoh: it's KDE4 and the right time
>> to fix such things ;)
>
>Actually it might be easier to do it this way, would have to change 4
> files kconfigbase.{cpp,h} and kconfig.{cpp,h}.
>Rename kconfig.{cpp,h} to kconfigini.{cpp,h} and rename KConfig to
> KConfigINI. Rename kconfigbase.{cpp,h} to kconfig.{cpp,h} and rename
> KConfigBase to KConfig.
>Then the hard part change all uses of KConfigBase to KConfig. It seems
> it would be easier this way, according to lxr.kde.org 3500 KConfigBase
> vs 27000+ KConfig .

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

There may be usecases where the application needs to use a specific 
backend. In that case, we can provide an enum to the front-end or a 
setBackend() function.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát "cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan 'eall'. Ástynt."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051104/26e7f2da/attachment.sig>