| Summary: | App renaming issue 3.5.13 -> R14 | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Kris <krisgamrat> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | bugwatch, darrella, trin |
| Priority: | P5 | ||
| Version: | R14.0.0 [Trinity] | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
|
Description
Kris
2012-07-12 09:58:21 CDT
Please provide some additional details. :-) Based upon the short description, I'm unsure but I'm guessing what you describe is related to the XDG updates. In starttde (starting at line 254) there is a snippet of code that calls another script named $TDEDIR/bin/r14-xdg-update. That script performs the necessary cleaning/scrubbing to update the user's profile configuration files. The only way the r14-xdg-update script won't run from within starttde is when the following exists in $TDEDIR/share/config/kdeglobals: [R14 XDG Updates] Updated=true If that does exist then please change the value to anything other than true and restart Trinity. That kdeglobals configuration key does not mean the r14-xdg-update script can't be run again, only that the script will not be run again from within starttde. Users can run the r14-xdg-update script manually any time they want. With that said, the r14-xdg-update script has not been tested in a robust manner. There could be some spots the script misses. Possibly you have discovered one of those spots. I never tested the script against the QuickLauncher app simply because I don't use the applet. :-) I would be grateful if you would help with that testing. We need to learn what is embedded in the related configuration file or possibly what is hard-coded in the sources that possibly has not been updated by the r14-xdg-update script. I need to experiment a little with the applet and learn more about any related configuration files. Which applications have you added that are different from the default apps? Knowing that probably will help. Regarding a way to account for the mishap, well, that is what the development branch is for. :-) A note about running $TDEDIR/bin/r14-xdg-update manually: When kdeglobals is already modified to "true," the r14-xdg-update script has to be run with the "force" parameter being passed, like this: r14-xdg-update force Good news! I installed the QuickLauncher applet and looked at the respective config file. The r14-xdg-update script does not address the way that config file stores information. hence, the results you reported. The script can be fixed and I'll push an update as soon as practical. :-) Short term solution (this might require first exiting Trinity for the changes to be permanent): * With a text editor, open the QuickLaunch config file. The file will be named something like this: launcher_panelapplet_yqjshb3iku2cwxc5d4lm_rc. * Change all occurrences of kde- to tde-. * Save the modified file and restart Trinity. The default config file from 3.5.13 will look like this: [General] Buttons=SPECIAL_BUTTON__SHOW_DESKTOP,kde-Home.desktop,kde-konsole.desktop,kde-KControl.desktop,kde-Help.desktop,kde-kwrite.desktop The default R14 config file will look like this: [General] Buttons=SPECIAL_BUTTON__SHOW_DESKTOP,tde-Home.desktop,tde-konsole.desktop,tde-KControl.desktop,tde-Help.desktop,tde-kwrite.desktop I pushed an updated r14-xdg-update script to GIT in commit c839bb9a. The "bad news" is from my testing, once a user starts TDE with a default quick launch config file that has not be updated with the XDG updates, that default config file is unfixable. I only tested with a default config file. Possibly then your customized quick launch can be repaired. Possible remedies for your personal situation: 1.) Exit Trinity. Manually run the r14-xdg-update script using the 'force' parameter. As I don't know how you personalized the quick launcher applet, I don't know what results you'll see. 2.) Exit Trinity. Restore the configuration file from backups. Before restarting Trinity, manually run the r14-xdg-update script using the 'force' parameter. 3.) Remove the applet from the panel, reinstall the applet, and then repopulate as necessary. This last remedy is least preferred but hopefully only requires a minute or two to rebuild. The latest version of the r14-xdg-update script should avoid the problem you experienced. I will leave the bug report open for a few days. (In reply to comment #1) > Please provide some additional details. :-) Based upon the short description, > I'm unsure but I'm guessing what you describe is related to the XDG updates. I'm not sure what XDG is. You got it exactly right regarding the QuickLaunch applet -- the icons still referred to the k* apps from 3.5.13 instead of the t* apps from R14. In case it still matters for the fix, here are my QuickLaunch items (listed in order left to right) Show Desktop Konsole KCalc Kwrite LibreOffice Konqueror Google Chrome Kontact Kopete Konversation Of those, only two were not affected by the upgrade (the two non-TDE apps). The rest were replaced by generic icons (what looked like a blank piece of paper), and returned an error saying something to the effect of "app not recognized" or "action not recognized" (I can't remember exactly what it said). I've already redone my QuickLaunch, but if you need the updated script tested, I can restore the QuickLaunch from backup when the script makes it to the next nightly build. The one detail I left out for the desktop shortcuts is that it only affected the shortcuts I added manually. Most of the icons I added were through the Tmenu -> {right click an app} -> Add to Desktop. The only exception was the first icon I added, which was through {right click desktop} -> Create New -> Link to Application (after which I realized I can add them through the Tmenu as described before). You don't have to test the script, although that would be nice. :-) I'm confident the updated version will avoid the quick launch problem from now on. If you test, make a backup of the current launcher_panelapplet and kickerrc config file. That way you can restore those files after testing without recreating everything again. kickerrc contains a reference to the launcher_panelapplet config file. You'll have to exit Trinity to restore those files because I don't think they can be manually edited during a live session. Thanks for reporting and helping! I can confirm that the default quicklauch applet for home is added with malformed 'URL'. The quicklaunch defaults for kcontrol and help are simply gone and not installed by default anymore. Additionally, the 'My Computer' icon on the desktop with shorcut to media:/ no longer works and opens 'dolphin' of all things by default when you click on it. Is that with the latest script from GIT? If yes, then please post a copy of the problematic launcher config file. Regarding the quicklaunch defaults for kcontrol and help, I have them here. If you mean they are lost after migrating a KDE3 profile to Trinity, refer to Comment 3. If you create a new copy of the quick launcher, the kcontrol and help icons should be there. If you are migrating your 3.5.12 profile, then you have to first run the migratekde3 script. If you are updating from 3.5.13 then you should not need to run that script. The latest r14-xdg-update script should now correctly update the quick launch config file. If that is not happening then please post a copy of that file. The quick launch bug was fixed in GIT commit c839bb9a, 2012-07-12. Thanks for reporting! |