Kevin Kofler wrote: > 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 If a setting in a conf file is invalid, there should be an error message logged. This is IMO the biggest issue with kde debugging. Where is a decent log file? There is ~/.xsession-errors, but it's almost useless. It doesn't include 1) name of app logging message 2) time