Version: (using KDE 4.1.0) Installed from: SuSE RPMs I recently upgraded from KDE 3.5.9 to KDE 4.1; KMail does not seem to have migrated the old settings (filters, accounts, identities, etc.). For people with large numbers of accounts, identities, and filters, this lack of backwards compatibility is quite a severe obstacle, as it would take many hours to reinput all the settings. Please have KDE4 versions of KMail automatically import settings from older versions.
This should be also be possible for the whole Kontakt Application(Organizer, Mail, etc)
are there any plans on this one? this is a true showstopper for me!
Can you check if the SUSE packages have been changed to use $HOME/.kde4 for KDE4 settings, or more generically if KDE3 and KDE4 packages have a different base directory? I think the applications are supposed to either read their older settings or have an upgrade script run at first start of the new version. However this assumes that the application actually sees its older version's config on first startup, which can fail if the location for either version has been changed and no external upgrade tool copied the data.
i experience this using gentoo ebuilds, the OP uses suse
*** Bug 180676 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > i experience this using gentoo ebuilds, the OP uses suse Can you check whether your ebuilds have the same local prefix? See http://bugs.kde.org/show_bug.cgi?id=180676#c1
$ kde-config --localprefix /home/naga/.kde/ $ kde4-config --localprefix /home/naga/.kde4.2/ So not here.
Could someone please explain what the resolution of "DOWNSTREAM" means in this case?
Again, where downstream has this been resolved? Have individual vendors provided KDE3->KDE4 import tools for KMail? If so, where can I get them?
Debian has a tool called kaboom, which is automatically installed as a dependency. It's supposed to work very well :) (it did for me) Debian switched back to ~/.kde for settings anyway, so future upgrades should be easier.
According to <https://features.opensuse.org/306350> openSUSE has a command-line tool called kde4-migrate, which is completely undocumented, and also doesn't seem to properly migrate the KMail settings. I'm not even sure what it's actually doing, as it doesn't produce any output. Just now I tried manually copying the ~/.kde/share/apps/kmail, ~/.kde/share/config/kmailrc to the relevant places under ~/.kde4, and then started up KDE4 KMail. It appears that everything (filters, sending/receiving accounts, mail folders, etc.) apart from identities was successfully imported. (However, I didn't play around much, so it's possible things are broken.) I'm still not sure why this feature was marked as RESOLVED/DOWNSTREAM. Why should it be the responsibility of vendors to provide the import tool? Only the KMail developers know the difference in kmailrc file formats between KDE3 and KDE4. There's no need for each vendor to code its own importer which does the exact same thing.
(In reply to comment #11) > Just now I tried manually copying the ~/.kde/share/apps/kmail, > ~/.kde/share/config/kmailrc to the relevant places under ~/.kde4, and then > started up KDE4 KMail. It appears that everything (filters, sending/receiving > accounts, mail folders, etc.) apart from identities was successfully imported. If you copy the emailidentities file directly, it might still work. If there was something to import KMail would have done that during its startup. > I'm still not sure why this feature was marked as RESOLVED/DOWNSTREAM. Why > should it be the responsibility of vendors to provide the import tool? They don't have to if the allow Upstream(KDE) to use its own upgrade mechanism. However, if a distributor changes code of one KDE version to behave different than the other KDE version, they'll have to provide for a migration path compensating this additional difference. > Only > the KMail developers know the difference in kmailrc file formats between KDE3 > and KDE4. There's no need for each vendor to code its own importer which does > the exact same thing. Right. That's why there are respective scripts for KDE's config upgrade mechanism. Vendors only need to code their own importer/migrator if they change KDE in a ways that makes it impossible for KDE's migrator to work.