I haven't seen that bug before. :-( When I rebuild my package set I uninstall all TDE packages and then install the new packages. I don't use my package manager. In other words, I'm basically installing fresh each time. So we start with some basics: Does this happen with a fresh $HOME/.trinity profile or an existing profile? Did you install R14 fresh like I do or as an "upgrade" with your package manager? Can you start other apps through the TDE menu? Is kcontrol the only app that won't start through the menu? Can you start individual kcontrol modules through the menu? Do you have KDE3 installed concurrently with Trinity? Do you have KDE4 installed concurrently with Trinity? The default TDe menu is installed to /etc/trinity/xdg/menus and is named applications.menu. There is an optional menu installed in the same location named applications.menu-no-kde. That optional menu will prevent KDE# or KDE4 apps from appearing in the TDe menu when either is installed concurrently with TDE. Otherwise the default menu will show KDE3/KDE4 apps with a "[KDE]" appendage in the menu item. So ensure the file date stamps of those files look correct and that you are not using an old menu. The applications.menu file should be 25,875 bytes in size and applications.menu-no-kde should be 16,182. With that all said, as you updated to R14 from 3.5.12 rather than from 3.5.13, quite possibly there are some remaining corner cases that the r14-xdg-update script does not cover in your profile that might cause this problem. Darrell

Those are not the latest menus from tdebase? I don't know that that location makes any difference. Is that where you always have installed the Trinity menus? Do you use /etc/trinity/xdg? The quicklaunch bug was fixed in commit c839bb9a, Thursday July 12. Make sure you are building with tdebase pulled to date. Do you have a backup copy of your 3.5.12 profile before moving to R14? If you do then we can methodically troubleshoot our way through this. I just now found a corner case of some files that need to be updated related to Input Actions, although not related to the other bugs you report. Regardless, looks like we both stumbled across some corner cases that need to be addressed in the r14-xdg-update script. In parallel hopefully you can figure out why you don't have the latest menus? Darrell

On 07/17/2012 05:31 PM, Darrell Anderson wrote: <snip> Yes, this is where the menus have always gone. They are totally FUBAR. All apps are dumped in 'Lost & Found'. There are menu folders that are moved around in the menu tree. 'Terminal Applications' is now under 'Internet'?? It used to be under System. Something must have 'blown up' regarding the menu. I've never seen such a mess. Now the questions becomes how do we figure out what happened? Can I just delete all the menus and have them regenerated somehow? The GIT pull was from 7/15. Yes. I have both ~/.kdemod3 (3.5.12) ~/.trinity (R14) I just now Yep, This is exactly why we need a "Code Freeze" and 10 days to identify and fix. I'm in. I have the install and several recent package sets we can work from. I'll have a list together soon and let's start putting our heads together. Do you want to start a new etherpad? -- David C. Rankin, J.D.,P.E.

Okay. I expect to be close to my computer this evening. The basic test method we want to use each time we try anything: * Ensure your original 3.5.12 profile is always safe or restorable from backups. :-) * Restore/copy the 3.5.12 profile as $HOME/.trinity. * Start Trinity. * See what breaks: one thing at a time. I see a potential snag. Your 3.5.12 profile directory is named $HOME/.kdemod3. I believe Arch had started KDE3 mod before Trinity started. The migratekde3 script does not look for that specific name because I never knew about that name, but I'll update the script. I think a 3.5.12 profile is essentially a KDE3 profile. If true then I'll do some testing here copying a $HOME/.kde3 profile to $HOME/.trinity and see what breaks. I always ran the migratekde3 script and you probably never have. I'm wondering what happens when you run the migratekde3 script against your 3.5.12 profile. Perhaps that fixes a lot, some of which the r14-xdg-update script does not touch. If you want to test the migratekde3 script you can temporarily edit the script to look for $HOME/.kdemod3 rather than $HOME/.kde3. Darrell

David, I pushed a patch to update the migratekde3 script to include $HOME/.kdemod3 as a KDE3 profile directory. You don't need to rebuild tdebase. Just 'git pull' tdebase and then copy the file from the sources to $PREFIX/bin/. Because no renaming changes occurred until 3.5.13 and thereafter, I am treating 3.5.12 profile directories as essentially KDE3 profiles. Therefore you might want to test the migratekde3 script against your $HOME/.kdemod3 profile. The script will create a $HOME/.trinity profile along with appropriate scrubbing. The r14-xdg-update script is run once from within starttde and performs a different set of scrubbing. Make sure your kdeglobals does not contain an [R14 XDG Updates] key group or r14-xdg-update won't run when you start TDE. If the migratekde3 script helps you, then we will need to figure out how to automate running migratekde3 against pre 3.5.13 profiles. The challenge is the script is not designed to run against an existing Trinity profile. I started to look into that and things got messy. Darrell

The updated FAQ in the help handbook index references the migratekde3 script (question 4.15). Unlike the r14-xdg-update script, which is necessary, we don't want to automate using the migratekde3 script anywhere. There is no way to predict whether a person is migrating from an old KDE3 profile. I have tested the migratekde3 script fairly well, but like any software, only through my perspective. I don't use other distros and I don't know what quirks or corner cases might exist with other distros. The latest version now recognizes ~/.kdemod3 as a KDE3 profile, thanks to your help. As I mentioned, We should consider treating Trinity <= 3.5.12 as a KDE3 profile because we did not start serious or massive renaming until 3.5.13. But I don't have a 3.5.12 or 3.5.11 setup to test migratekde3. Thus far, you're the only person who can help with that. :) Darrell

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

Please be sure to download the latest of both scripts. I pushed updates today. Darrell