On Tuesday 21 April 2009 00:29:48 ianseeks wrote:

Thats great news. Its something that should be have been inbuilt from the beginning where a new version interrogates the existing rc files and imports all useable config data to the new one and ignores the old and no longer used config bits from the file.

This has existed in KDE since at least KDE 2 days. There is a mechanism that converts configs on version update. In the simplest version it allows for config keys to be renamed, but a developer also has the flexibility to pipe config files through a bash, python or perl script with all the flexibility that entails. Have a look at any significant KDE config file, like kmailrc - you will see lines like this at the top: [$Version] update_info=kmail.upd:1,kmail.upd:4,kmail.upd:5,kmail.upd:6,kmail.upd:7,kmail.upd:8,kmail.upd:9,kmail.upd:3.1- update-identities,kmail.upd:3.1-use-identity-uoids,kmail.upd:3.2-update-loop- on-goto-unread-settings,kmail.upd:3.1.4-dont-use-U OID-0-for-any-identity,kmail.upd:3.2-misc,kmail.upd:3.2-moves,kmail.upd:3.3- use-ID-for-accounts,kmail.upd:3.3-misc,kmail.upd:3.3b1- misc,kmail.upd:3.4,kmail.upd:3.4a,kmail.upd:3.4b,kmail.upd:3.4.1,kmail.upd:3.5.4,kmail.upd:3.5.7- imap-flag -migration-2 This shows which update scripts have already been run on this file, giving "at most once" semantics. The update scripts and control files (.upd) are in /usr/share/kde4/apps/kconf_update/ The reason extra work is necessary for seamless KDE 3 to KDE 4 PIM is mainly because the email dist lists can now be stored on a groupware server, so a file-mangling update system is not sufficient. But filter update problems may need extra work in the kconf_update scripts, so let me know if you have any.

This would be a big advance in user friendliness. What would also be a good thing is a ".kontact" folder that has subfolder links to all the elements of how kontact is configured so you can do an easy single line rsync backup of the .kontact folder instead multiple lines and it would also make upgrades to newer versions a lot simpler.

Generally we work on the .kde level, since the schema by which all KDE apps store there config and data is (supposedly) well known. But I might include a section on how this works in the KDE admin workshop in the upcoming openSUSE Community Week. Will