KDE3TO4

Utilities

Source (required if based on other people's work):

0
Score 75%
Description:

KDE3TO4 is a wizard implemented as a set of modular bash scripts to help users migrating from KDE3 to KDE4 by easily migrating settings for various applications from their old KDE3 settings directory to their new KDE4 settings directory.
It requires that you keep the two directories in separate locations. Kubuntu for example already does this for you, Fedora users will have to move their KDE3 directory ($HOME/.kde) to a new location (such as $HOME/.kde3) before installing KDE4.

The modular design makes it easy for anybody to add support for any application and it is my hope that a lot of this support will be provided by various application developers themselves as they are uniquely able to identify possible quirks in migrating a specific app. Having said that I will accept all good contributions into the main tree, regardless of who wrote them. The amount of work for a given app is very little on average and the wizard takes care of integrating it into the overall process easily.
You can send new modules me at aj.venter@datacash.co.za
Last changelog:

10 years ago

CHANGELOG:
Version 0.0.4: Added support for migrating konqueror searchproviders. Thanks to NhJm.

Version 0.0.3: Fixed a bug in the konqueror script
Added several more important blacklists. Special thanks to Aaron for the list.

Version 0.0.2: Switched backend to KIOClient for better userfriendliness, desktop integration and features
Includes experimental new all_apps script which handles almost all applications,
with blacklist and exception support to prevent breakage.
Includes a script to migrate amarok1.x settings.

Version 0.0.1: First release.
Includes scripts for kopete and konqueror.

yoho

9 years ago

Hi,

I've just tested your program with Mandriva 2009.0 and it works rather good. I was a bit skeptical at first, but actually I really like the fact you can choose to override your existing kde4 settings or not, application by application. It definitely helped in my migration so a big thanks.

Now just one more thing : could you add support for Mandriva by just adding a sentence saying KDEROOTDIR for Mandriva is "/usr" (yes no typo :-)). Also, please take into consideration /usr/lib/kde4 exists too in Mandriva and for the moment, Mandriva is detected as a kubuntu !

Thanks again

Report

mrsaccess

9 years ago

Nice work! I think though that it has two problems:

- No uninstall script.
- It depends on mirrordir which isn't available for many distributions (ie Gentoo).

Report

yoho

9 years ago

A package for this application would take care of those two issues...

Report

MAWSpitau

10 years ago

I have tried your scrip and it did something. But for example it does not transported on of my email-accounts from kde3 to kde4 ... No calendar was transported. Only the standard-address book was copied. So, to be honest not realy usable or did I make something wrong? I am using Kubuntu hardy.

Report

C

ajventer

10 years ago

The things you mention should actually happen. It sounds like you used the all-apps module - so I am interested in why it failed. The program is still fairly experimental so there could be many reasons.

The most obvious one being that you had kmail open at the time ? If it's running, it won't be able to copy accounts or mails in as the current running version will overwrite the configs.

I must add that I have only done limited testing on kde-pim modules so far but I am working with the kde-pim developers to improve that part.

Report

MAWSpitau

10 years ago

No, nothing but KDE4 was running, no applications or programms. But I do not remember as WHO I ran your tool. It could be, that I used it as root (sudo -s), so that could be the problme somehow. I will delete my .kde4-directory and give it one more try as me ;) And I will report about the result.
BTW: I have no idea what you are talking about, if you say: "all-apps module" I had no choice to choose another module. But to be honest "all-apps" sound good to me! :D

Report

MAWSpitau

10 years ago

No difference. :( Kopete is done well, but the whole PIM-thing does not work :( What kind of information do you need, for a propper debugging?

Report

C

ajventer

10 years ago

Firstly let me explain. There are a few modules in the system, that run sequentially, all-apps is the first one, and does the PIM stuff. After it is finished you should get asked about other modules, including modules for kopete, konqueror and amar0k 1.x

If you are not getting those prompts then it means something else is wrong - the script is apparently crashing before it finishes.

For starters, try running it from a console and logging the output to a file and send it to me - that will already help me see what happened. Based on that, I will ask for more if I need it. My email address is aj@outkastsolutions.co.za

Report

AndreSomers

10 years ago

If I try to download, I still get a package called version 0.0.2, instead of 0.0.3. Is that a faulty name, or do I actually get an outdated package?

Report

C

ajventer

10 years ago

Sorry about that, I made a typo in the update, it's fixed now and you can get the right package from kde-apps.org as well.

Report

KevinKofler

10 years ago

Why would one want to use this script with Fedora in the first place? The entire reason we don't use a separate settings directory for KDE 4 is so you don't have to copy config files around.

Report

C

ajventer

10 years ago

But the fact that a huge amount of KDE3 settings are NOT compatible doesn't bother you ?

In fact - nearly all the changes in 0.0.3 has been blacklisting entries that cause breakage if copied.

Having a seperate kde4 settings directory just makes sense at this time.
What is worse is that the fedora setup actually makes it impossible to run both KDE3 and KDE4 for a while to ease the migration process.
I understand the reasons for the decisions (I read the FAQ) entry, I just don't agree that they outweigh the reasons other distro's have not to do the same.
What I can tell you is that, this was one of the prime reasons I opted to use kubuntu rather than fedora 9 on my home machine - for me, being able to run them concurrently is, at this stage, critical (not least - to be able to develop this project).

Report

KevinKofler

10 years ago

Your blacklist contains:
* amarok: Fedora 9 still ships Amarok 1.4. If the Amarok 1.4 settings break current Amarok 2.0 prereleases, then that's a bug in Amarok, which will hopefully be fixed in Amarok 2.0 final. I know the Amarok team is interested in fixing migration issues, they're also working on a collection database migration script. And if no better solution can be found, it's easy to provide a kconf_update script which removes all the offending settings.
* mailody: Fedora never shipped any version of Mailody, so migration issues are not our problem there. (Once the KDE 4 version will get packaged, it will be a new package.) Just as for Amarok, KDE 4 Mailody is still in alpha, and if the settings from the KDE 3 version break the KDE 4 version, that has to be fixed either in Mailody or with a kconf_update script.
* kdev: That blacklist entry doesn't work at all as there's no kdevrc or /usr/share/apps/kdev. If you're trying to blacklist kdevelop settings: KDevelop 4 is far from ready, Fedora 9 still ships KDevelop 3 and Fedora 10 will likely too. It's the same as with Amarok: the migration issues will hopefully be fixed in time for the release. And in the meantime you should fix your blacklist so it actually blacklists all kdev*.
* kdesktop, kicker, ktaskbar: Those settings are completely ignored by KDE 4 anyway.
* kget: Why did you blacklist that one?

Also keep in mind that settings are only a problem if they actually break something. If they're ignored, then of course it makes sense for you to blacklist them because copying them is useless, but no special action is needed for us in Fedora, as the settings don't do any harm if they are ignored.

In short: except possibly for KGet (which you added to the blacklist in 0.0.3, in fact, it's the only addition which might make any sense at all), you're only possibly working around bugs in 3 individual applications, all of them alpha versions, and none of which affects Fedora 9. If any such issue actually affects Fedora in the future, we will provide kconf_update scripts to fix it. But we expect these issues to be fixed where they should be fixed: upstream.

As for KGet, can you please explain what the issue which prompted you to add it to the blacklist is? Is it really caused by old configuration? KGet in KDE 4.0 is broken even with a fresh .kde directory, upgrading to 4.1 fixes it (see http://bugs.kde.org/show_bug.cgi?id=161760). So someone might be mistaking a plain application bug for a configuration issue. But if there really is a configuration issue, then there too kconf_update is the proper solution.

Report

Rinse

9 years ago

>>Why would one want to use this script with Fedora in the first place?


Why deny people the choise to do whatever they want to do with their pc?

Report

KevinKofler

9 years ago

Because this script is completely useless on a distribution which does not use a separate .kde4 in the first place.

Report

C

ajventer

9 years ago

That is just not true - if the user backs up his kde3 directory before installing fedora (e.g. mv .kde .kde3) then the script will work just fine.

Report

KevinKofler

9 years ago

It will work, but that doesn't make it useful. It will just copy the files back to where they started in the first place, what sense does that make?

Report

C

ajventer

9 years ago

>* amarok:
Amarok is blacklisted because there are two incompatible versions and it's impossible to know which one the user wants so it should not be automatically migrated. Instead there is a custom module for amarok1.x if the user wants to keep using that with kde4. If he is switching to amarok2 then, at this stage at least, it's up to amarok to import settings or start fresh.

>* mailody: Fedora never shipped any >version of Mailody, so migration >issues are not our problem there.
Mailody is blacklisted based on a request from the developer - because the kde3 and kde4 versions are entirely incompatible. Just because fedora doesn't ship a package that does not mean users don't have the package ! People install things you know. Users of fedora8 may have added it to kde3 there, and with fedora9 as they move to kde4 those settings should be left away because when the new mailody is out they will probably want it and it shouldn't be broken by this script.

>* kdev: That blacklist entry doesn't >work at all as there's no kdevrc or >/usr/share/apps/kdev.
It DOES work - you just didn't read how blacklisting is implemented right. It ignores not only kdevelop but all folders and rc's that start with kdev - now YOU may not have any, but there are LOTS. Specifically all kdevelop plugins for kde3 install to kdevxxxx folders - and these are completely incompatible as are kdevelop itself.
As with mailody - this blacklist was directly suggested by the main developers of kdevelop.
The only fix needed here is to modify it into a regex, right now it blacklists any name that CONTAINS kdev, it should blacklist only those that START with it. That's on the todo list for 0.0.5

>* kdesktop, kicker, ktaskbar: Those >settings are completely ignored by KDE >4 anyway.
No they aren't - they are imported by kconf_update and BADLY too. I have tried it - kconf_update handles these - just terribly and leaves you with a mishmash of plasmoids for your ~/Dekstop folder instead of a folderview for example.
The rest are left out since they are incompatible -why waste a user's disk space copying files that will be ignored ?
>* kget: Why did you blacklist that one?
Because the settings are incompatible with kget4. Yet again, this was requested by the kget lead devs.

What you don't seem to understand is that I am not developing this in isolation, I am constantly in communication with all the kde-developers on the main mailinglists sourcing information and trying to make this tool really useful. I want it to be included in kde4.2 by default (as it works better if it's run right after kde4 installation before your apps can create their own settings- not technically better, user-effort better) - and do you really think anybody would try to get something into kde proper without working in conjunction with the rest of the KDE community ? Once 0.0.5 is out, I will request my proper KDE SVN account and move it into the playground repo - from whence I hope it will grow to be a standard feature on a new kde installation.

I'm trying to do something useful for people. A lot of people DO seem to think it's useful if I look at the other comments and download rates... why exactly are you flaming my project ?

Report

KevinKofler

9 years ago

> It DOES work - you just didn't read how blacklisting is implemented right.

I read it exactly and it doesn't work.
> J=`basename $I`
> if ! echo $BLACKLIST | grep $J ; then

This picks the basename of the folder or file, then checks if it's contained in the blacklist. As it searches for the basename in the blacklist and not for the blacklist entry in the basename, it will not find entries where the blacklist entry is not the exact basename (or the basename is a substring of the blacklist entry, which is the wrong way round, e.g. blacklisting xxxamarokxxx will "work" to blacklist Amarok). Searching for foobar in "bla foo baz" will fail.

> Because the settings are incompatible with kget4.

But does it actually break anything? If so, KGet should be fixed. If not, the settings do no bad there, it's OK for you to blacklist them, but it's not an argument against the Fedora setup.

> I want it to be included in kde4.2 by default

And that will be too late because people will already have migrated to KDE 4 by then, and at that point your tool can only break things.

A migration script like that is the wrong solution (it could have worked if it had been ready in time for 4.0, but not now). kconf_update is the way to handle the migration. You can count on me and other Fedora maintainers strongly opposing the inclusion of this tool into KDE, and Debian and Kubuntu will probably join us, as Debian never used .kde4 (just like us) and AFAIK Kubuntu is dropping it in Intrepid.

If applications choke on old settings, they need to be fixed, or get a kconf_update script written, not rely on being blacklisted by a migration tool which can only work as intended on some distributions and which has to be run manually.

Likewise, if kconf_update badly migrates KDE 3 kdesktop and kicker settings, then the script should be fixed, or disabled if it can't be fixed, it makes no sense to hack around it by not copying the files. All the kconf_update scripts were written for a reason, if you remove (avoid copying) files to avoid getting them processed by kconf_update, you're going against the intentions of whoever wrote that script (a developer aiming at a migration as seamless as possible).

> I'm trying to do something useful for people.

But your instructions telling people to use it on Fedora where it is not needed in the first place, by creating the problem (a separate .kde4) just so it can be solved, are not useful nor helpful.

> why exactly are you flaming my project ?

I'm not flaming your project, I'm only saying that 1. it is useless for Fedora and 2. a separate .kde4 is a bad idea and your project can only solve part of the problems it causes. And I don't disagree that it can be useful for distributions which unwisely chose to use a separate .kde4.

Report

galarneau

10 years ago

That's a really great idea! Thanks for that. I hope you'll get help (alas, I have no technical skills).

Report

10 years ago

CHANGELOG:
Version 0.0.4: Added support for migrating konqueror searchproviders. Thanks to NhJm.

Version 0.0.3: Fixed a bug in the konqueror script
Added several more important blacklists. Special thanks to Aaron for the list.

Version 0.0.2: Switched backend to KIOClient for better userfriendliness, desktop integration and features
Includes experimental new all_apps script which handles almost all applications,
with blacklist and exception support to prevent breakage.
Includes a script to migrate amarok1.x settings.

Version 0.0.1: First release.
Includes scripts for kopete and konqueror.

product-maker 9 40

File (click to download) Version Description Packagetype Architecture Downloads Date Filesize DL OCS-Install
Pling
Details
license
version
0.0.4
updated Aug 21 2008
added Jul 23 2008
downloads today
0
page views today 1
System Tags app software