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

We need to figure out why your tdelibs package does not include the menus from the sources. Or why they did not install correctly. In GIT the menus are located in tdelibs/kded. There are only two menus there we are concerned about. In a pinch you can just copy those. You should not need to restart TDE, but you will need to use the menu once or twice to force TDE to update the menu on its own. Okay. Open your quick launch config file with a text editor or viewer. The file name is goofy, like this: $TDEHOME/share/config/launcher_panelapplet_dyrwtplrzeqcrk4kmi9m_rc Look for any occurences of kde-. If you see that, then exit TDE and run the r14-xdg-update script using the 'force' parameter. By the way, have you ever run the r14-xdg-update script against your 3.5.12 profile? If you don't know or are uncertain, open $TDEHOME/share/config/kdeglobals and look for the following: [R14 XDG Updates] Updated=true If you find that in your 3.5.12 profile, then change the key value to anything other than true or exit Trinity and run the r14-xdg-update script with the 'force' parameter. Until about a dozen usability bugs and numerous build issue bugs are resolved I think we are a ways off from a freeze. Just my opinion. The problems you are experiencing are growing pains of somebody moving from 3.5.12, which I don't think anybody has done yet. You're the guinea pig. :-) Nah, we can keep things going here. I have a feeling the problems you are seeing are 1) the menus and 2) corner cases with the r14-xdg-update or migratekde3 scripts. I don't have a 3.5.12 setup. I doubt I could create one that would replicate your setup. So we go one step at a time. The good news is I have been using R14 for several weeks. Everything works. We simply need to learn what breaks with a 3.5.12 migration and we'll be okay. Darrell

On 07/17/2012 06:22 PM, Darrell Anderson wrote: OK, I'm on the rebuild and I do have the _complete_ 3.5.12 profile :) -- David C. Rankin, J.D.,P.E.

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