<br><br><div><span class="gmail_quote">On 10/1/07, <b class="gmail_sendername">Nhuh Put</b> <<a href="mailto:nhuh.put@web.de">nhuh.put@web.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

Von: Thomas Braxton<br>Gesendet: Dienstag, 2. Oktober 2007 00:16<br>An: <a href="mailto:winter@kde.org">winter@kde.org</a><br>Cc: <a href="mailto:kde-core-devel@kde.org">kde-core-devel@kde.org</a><br>Betreff: Re: [RFC] KConfig merge

<br><br>> On 10/1/07, Allen Winter <<a href="mailto:winter@kde.org">winter@kde.org</a>> wrote:<br>> > PutHuhn has volunteered to put the effort into finishing the KConfig<br>changes,<br>> > 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.

<br>I know you have provided patches for kdepimlibs, kdelibs and kdebase, but I<br>can't help with porting the other stuff, because I can't compile most<br>things.<br>My idea was to keep KConfigBase, make everything in it but a few methods for

<br>group management deprecated (groupList and hastGroup and such stuff) and let<br>KConfigGroup inherit KConfigBase like in kde3. This would make adding<br>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.

<br><br>I wanted to do this already earlier this week, but I had a very bad cold and<br>didn't do much of anything :(<br><br>        PutHuhn<br><br></blockquote></div>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.

<div>About making the use of char*, QByteArray, and QString more consistent I think I agree, depending on what you mean.</div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><div><br class="webkit-block-placeholder">

</div>