[RFC] KConfig merge

[Thomas Braxton]

On 10/1/07, Nhuh Put <nhuh.put at web.de> wrote:
>
> Von: Thomas Braxton
> Gesendet: Dienstag, 2. Oktober 2007 00:16
> An: winter at kde.org
> Cc: kde-core-devel at kde.org
> Betreff: Re: [RFC] KConfig merge
>
> > On 10/1/07, Allen Winter <winter at kde.org> wrote:
> > > PutHuhn has volunteered to put the effort into finishing the KConfig
> changes,
> > > but it will take him longer than midnight to finish... probably around
> noon in Europe.
> >
> > Since I came back home sick, just curious about what changes?
>
> It's not that easy to remove KConfigBase, because it's is used in many
> places; especially the dreprecated read and write methods.
> I know you have provided patches for kdepimlibs, kdelibs and kdebase, but
> I
> can't help with porting the other stuff, because I can't compile most
> things.
> My idea was to keep KConfigBase, make everything in it but a few methods
> for
> group management deprecated (groupList and hastGroup and such stuff) and
> let
> KConfigGroup inherit KConfigBase like in kde3. This would make adding
> support for nested groups really easy (I plan to do this for KDE 4.1).
> I would also like do some other cleanups like removing KConfigFlags (it
> contains only one lonely enum), make the use of QString, QByteArry and
> const
> char * more consistent and some other small things.
> I will commit the changes to Thomas' work branch a soon as they are ready.
>
> I wanted to do this already earlier this week, but I had a very bad cold
> and
> didn't do much of anything :(
>
>         PutHuhn
>
> KConfigBase was very easy to get rid of s/KConfigBase/KConfig/ for the
most part. As for the nested groups I think it can be done without deriving
KConfigGroup from KConfigBase, I already have an idea of how to do it
similar to QSettings with only one, maybe two pointers in
KConfigGroupPrivate, and bring back KConfigGroup::group(). IMHO deriving
KConfigGroup from KConfigBase makes KConfigGroup way too heavy, pulling in
many things that have nothing to do with a single group, right now
KConfigGroup is very light and I think we should keep it as light as
possible since in some places people are creating them inside loops.About
making the use of char*, QByteArray, and QString more consistent I think I
agree, depending on what you mean.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20071001/b52eff5f/attachment.htm>