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 =)
Subscribe to:
Post Comments (Atom)
6 comments:
It might be good to outline how does it relate to KConfigXT, to me (from the outside) those things look very related.
What about - either builtin or external test - functionality wrt config versioning, plausibility/correctness checks (e.g. "Does referenced file foo exist or has it been moved/renamd maybe?", "Is key:value pair foo valid for application version x.y.z?"), so issues show up quickly on a test platform, doing an update as every user does.
kconf_update is too dependent on the sharp eyes of the subset of KDE developers, who actually run extra test environments and (mostly minor, but nevertheless annoying) things broke a couple of times between KDE 3.x releases.
"What about - either builtin or external test - functionality wrt config versioning"
the .kcfg xml files could give a good place to start mining data. such a test harness would take a fair amount of work, but would be very nice from a q/a perspective. as usual, it comes todwn to having someone with the time and interest to get it moving.
What's with Plasma, when will you have something to show off there?
would it be considerable to use RDF (with RDF/XML or an other more compact serialization) to store the configuration of KDE 4?
This would have a number of benefits - among other:
* it would be simpler to export the configuration or to upgrade configuration (from KDE 4.0 -> KDE 4.1)
* merging configuration comes for free: e.g., kde-look.org could have custom configuration files.
With RDF to describe KDE's configuration, a user can always merge the configuration of its computer at home with the configuration of its computer at work!
> it comes todwn to having someone with the time and interest to get it moving.
This argument is of course always right. The problem is that the groundwork has to be done on the config storage side, not on the tool side to extract and check the information.
You simply can't distinct, if a referenced file has just been renamed, has been moved, went missing or still gets shipped, even though not referenced/used at all, if you only store a filename and not a hash of the file as well. You can't check for valid function values or ranges, if not every application ships with a configuration metadata file, specifying which key:value(, list, range) pairs are valid for a given config file and application version. Providing the data would of course be done by the application developers, so it isn't a big pile of work for a single developer.
Post a Comment