update: to clear up some apparent confusion, this post is about the kconfig class which kde apps use to read/write configuration data, desktop files, etc .. it's not about the control center =)
kconfig is being kicked into shape. first mkretz reworked things so that there is a KComponentData object which holds a collection of KAboutData, KConfig and KStandardDirs. this meant some changes to KConfig, namely using KConfigBase is most places rather than KConfig directly and having KConfig optionally take a KComponentData and letting that determine its lifespan. every app has a global componentdata object while plugins/parts/etc may have their own.
this seems to have inspired others. coolo and dfaure have been attacking kconfig in a branch. bools are replaced with enums in the API, KConfigGroup no longer subclasses KConfigBase and provides all the read/write API while that same API has been deprecated in KConfigBase. exciting times.
tomorrow i'll be merging in changes from another kconfig branch that have to do with making backends pluggable. this has a number of implications, mostly positive =) an interesting example is that KIO::SlaveBase has a subclass of KConfigBase, which dfaure pointed out to me today. looking at the code it's apparent how it's really just mapping the KConfigBase API to a non-file data source; in other words it would be much more suited (and the code read less "funny" =) if it were a backend. which is the plan (after having talked with waldo about it earlier today via email).
if all that goes well the next diabolical plan will be to look at the feasibility of merging KConfig and KConfigBase into one class. this was already accomplished once in that other kconfig branch, so it is doable =) the pluggable bakcend stuff has to happen first though.
end result of everyone picking away at this: kconfig will be extra sweet in kde4. so send cookies to the people who have been working on this rather technical and boring bit of code =)