<div>Hi</div><div>My name is Thomas Braxton, you may remember I was the one doing the refactor on KConfig. Real life got in the way and I wasn't able to finish. I haven't jumped back in to KDE development because I still don't have a permanent net connection. I've been trying to follow what's going on in KDE mostly through the Commit Digest, and I noticed someone is writing a backend for KConfig. So, I was wondering if the work I was doing is still wanted? The classes could have been merged a while ago since there was only two things that didn't work at the time; failing QByteArray test (which I believe someone else solved in trunk) and locales not fully implemented in KConfigIniBackend. Now it seems there are some small changes that need to be made to make it compile with the new interface, but it doesn't seem like much work. Since someone is actually trying to write a new backend, I figured the work I did should make it easier. He should only have to implement 2 functions in a KConfigBackend derived class to make a new plugin. The biggest changes from the current API would be: removing KConfigBase (it's superfluous since all KConfigBase objects are also KConfig objects, no need for a useless abstract base class) and change KEntryMap from a typedef to a class derived from QMap (this allows to remove some implementation details from the public API, the only classes that need to know about the implementation of KEntryMap is KConfig, KConfigGroup? and KConfig*Backend classes). The two changes above can probably be done today, the rest of the merging should be able to be done in the next week.
</div><div>So what do you think, should I merge or just forget about it?</div><div><br class="webkit-block-placeholder"></div><div>Thomas</div><div><br class="webkit-block-placeholder"></div>