Problems from old config files

[Kevin Kofler]

Patrick O'Callaghan wrote:
> We clearly need a way of dealing with this. I guess transparent updating
> is a lot to ask, but at least detecting obsolete config files and
> warning the user should be a high priority for future KDE releases.
> Would it be too hard for each config file to include a comment line at
> the beginning with the version of whatever KDE component created it, and
> new versions of that component to check the line for compatibility?

Well, in principle that's what kconf_update is for, but due to various 
limitations:
1. Several KDE apps will keep settings in memory and write them out if 
closed, not reloading changes made to the config file in the meantime. This 
breaks if kconf_update runs while the application is running. (This is 
particularly annoying with Plasma config files, kconf_update is basically 
useless for those.)
2. Not all known configuration file changes have corresponding kconf_update 
scripts.
3. Not all issues caused by old configuration files are known. Sometimes a 
setting which used to be valid isn't anymore for whatever reason and this is 
often very much non-obvious.
this doesn't always help.

For 1., either kconf_update or KConfig or both need fixing (I'd fix this in 
KConfig by writing any changes to disk automatically and by setting a 
KDirWatch on the config file to reload on-disk changes automatically, but at 
least Aaron Seigo clearly expressed his dislike for that solution and 
suggests having kconf_update talk to running applications over D-Bus 
instead), for 2., upstream developers need to do a better job of adding 
kconf_update scripts if they change the format of their configuration files 
(but ideally they should just not change it!), 3. is the biggest problem (as 
sometimes even the upstream developer of the application isn't aware of the 
issue nor its cause).

        Kevin Kofler