KConfig hierarchy redesign

[Michael Pyne]

On Monday 10 April 2006 05:56, Tobias Koenig wrote:
> Hi,
>
> the current KConfig inheritance hierarchy seem broken to me and maybe we
> should change it now, so when the application developer start to port
> their stuff they can use the new concept already.
>
> The current state is
>
>  KConfigBase
>
>   + - KConfig
>
>   |    + - KSimpleConfig
>   |
>   |    + - KSharedConfig
>
>   + - KConfigGroup
>
> The disadvantages I see with this concept are:
>
>  - KConfig pointers are used everywhere in KDE, so you can't pass
>    a KConfigGroup pointer there, also it's meant to be used as decorator
>  - Using KConfigBase everywhere seems a bit odd because of the strange
>    name
>  - Coolo mentioned on IRC that a prefered way could be to hide KConfig
>    completely and use KConfigGroup everywhere instead
>
> So maybe the following redesign could help a bit
>
>  KConfig (merged with KConfigBase)
>
>   + - KSimpleConfig
>
>   + - KSharedConfig
>
>   + - KConfigGroup
>
> Since except of KConfig only KConfigGroup inherits from KConfigBase, and
> that seems to be the wrong approach, why not merging these two classes
> to a KConfig?
>
> I'm not a KConfig guru, just a developer who doesn't like the current
> API, so maybe somebody with more knowledge could comment on it?

I like the idea, maybe aseigo has more input since last I knew he was trying 
to develop a Elektra binding for KConfig.

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060410/cdf0e053/attachment.sig>