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