KConfig revisited

[Thomas Braxton]

Hi
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.
So what do you think, should I merge or just forget about it?

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