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
