>   Here is another data-point on the menu issue. On the
> test boxes in virtualbox that have only had R14 on them and have been updated since
> February with each build, the menus and quicklaunch URLs are OK. The only box
> that got terribly hosed was the actual non-virtual box that I removed my TDE
> 3.5.12 install and replaced it with R14. That is the box that had the menus
> scattered and the quicklaunch malformed URL problem.
> 
>   Recall on the problem box, the 3.5.12 install was in
> /opt/kde3 and the profile was ~/.kdemod3. All 3.5.12 packages were removed before
> installing R14, and the ksyscoca in /var/tmp was removed. There was no migration
> script run, so the main culprit appears to be handling of the menu files in
> ~/.config/menus and /etc/xdg/menus. The new profile went in ~/.trinity, so the
> only issue I can see is the old menu files.
> 
>   I have not wiped the problem box yet to do another
> fresh R14 install. So let me know if you want anything else off it. Also, let me know
> if you think the /etc/xdg/menus files will cause issues on reinstall. I have
> deleted the ~/.config/menus files. Thanks.

Short answer, yes, I remain interested in case we are not covering some kind of corner case. Especially if there are many 3.5.12/3.5.11/3.5.10 users who will be updating to R14.

Long answer:

There are two scripts we use to massage an existing profile directory into compliance with R14. One script is called migratekde3, which is used to migrate an existing KDE3 profile to Trinity. The second script is r14-xdg-update, which is used to tweak an existing Trinity profile with various XDG changes we have made since 3.5.13. The two scripts do not address the same territory.

The migratekde3 script is optional and must be run intentionally. The migratekde3 script can run somewhat automated but only in the case when the r14-xdg-update script discovers that ~/.trinity is a sym link to ~/.kde3 (~/.kdemod3). In that case (not yet robustly tested) the script offers the user the option to break the sym link and migrate the KDE3 profile to Trinity. Otherwise the migratekde3 script has to be run directly by the user at the command line.

The r14-xdg-update script runs from within the starttde script, hopefully only once. Recently we added some dialogs and error messages should the script fail to run successfully the first time. We also have no mechanism in place to update profile files that are administratively locked or owned by root. At the moment we only offer a reminder message to check permissions.

The migratekde3 script knows the locations of ~/.kdemod3 and /opt/kde3. You did not run the script, however.

Users cannot use a previous KDE3 profile in Trinity without experiencing various problems. Based upon what I have seen of various 3.5.12 config files, a 3.5.12 profile is essentially a KDE3 profile. To continue using that profile means needing to use the migratekde3 script. Look at the migratekde3 script to see what kinds of changes are made to fix the profile.

The r14-xdg-update script attempts to scrub an existing $HOME/.config/menus/applications-kmenuedit.menu file. You wrote that you deleted that file and the system menu remained broken. Therefore we need to look at those system menu files.

The primary system menu file is named applications.menu.

Neither script attempts to fix existing system menus, nor should they. Check that your package management tools are removing the 3.5.12 system menus from /etc/xdg/menus. Then verify that your latest tdelibs package is installing applications.menu to your expected location of /etc/xdg/menus.

The latest applications.menu will contain references to TDE *.desktop file key names. If your 3.5.12 profile is not updated correctly, then your profile will be referencing KDE3 *.desktop key names and that would cause havoc in your menu.

To return to the original discussion, we have two areas in your case to understand. One, is your profile still essentially a KDE3 profile? When I looked at some of the files I concluded yes. Therefore you need to run the migratekde3 script.

The second area is whether your system is using the correct system menu. I don't know your build scripts or your system configuration. If you have more than one applications.menu on your system then that could cause havoc too.

We have no mechanism to validate how the system menu is created. The XDG_CONFIG_DIRS environment variable does get set in starttde and that variable controls where to look for menu files. Check that variable on your system and then check each of those paths for potentially conflicting menus.

At the moment we have no mechanism to warn users when they try to use an existing KDE3 profile in Trinity. We probably should. I haven't thought much about how we should do that. I could open a bug report, but preliminary discussion is welcomed.

I want to ensure we have 3.5.12/3.5.11/3.5.10 users covered. I have tested both scripts against a 3.5.10 profile and I am content the scripts wrok well. Yet I can't conceive of all corner cases. Thus far, you're the only additional test case where we can unravel any bugs unless some others volunteer too. If you can keep a copy of that 3.5.12 profile safely stored then we can keep testing. But we also need to determine whether the problem you describe is the profile or the system menus.

Darrell