The latest starttde update and new r14-xdg-update script were pushed to GIT in hashes 6ebf92cb and 5464fc6f. All changes revolve around R14 XDG compliance updates. I figured pushing to GIT was easier for folks to test rather than post as attachments to a bug report.

I moved the R14 XDG compliance updates to a new script named r14-xdg-update. In the GIT sources the new script is added to tdebase/r14-xdg-update and is installed to $PREFIX/bin, just like starttde. The new script can be run stand-alone.

starttde now calls this new script rather than perform the updates directly.

I updated the migratekde3 profile migration shell script in bug report 709 and pushed in GIT hash 6ebf92cb. In the GIT sources the migratekde3 script is added to tdebase/migratekde3 and is installed to $PREFIX/bin, just like starttde. This script is a stand-alone script and is not run anywhere automatically.

Compared to the initial XDG update snippets in starttde, the new r14-xdg-update script performs the following:

* Error checking against sym linked profile directories (a corner case but needed).

* Usage of a verbose X message box to warn about a sym linked profile directory, why an R14 XDG compliance update will not occur, what fails to function properly because of that missing update, and possible remedies available for the user.

* When run directly from the command line, r14-xdg-update asks the user to automatically break the sym link, and then will ask whether to migrate a KDE3 profile.

* Nominal validation tests that the XDG updates succeeded. When failures are detected then an X message box appears for each type of failure, thereby informing the user specifically what needs repair.

* Supporting a command line parameter named "force" that allows users/administrators to run the r14-xdg-update script even when the kdeglobals Updated key value is set to true.

* Fixed a few bugs found along the way.

* If all goes well, then the user sees nothing and everything should just work.

I have been testing all afternoon. :-) Everything is more robust, but I won't pretend I anticipated all usage methods or corner cases or that I found all bugs or did not introduce new bugs.

I have not yet added anything related to test the XDG updating against administratively locked files and directories. I am open to suggestions. I need to review the specifications of what can be locked in a Trinity profile and how that likely affects the XDG updates.

There are some "TODO" notes in the new r14-xdg-update script.

Please help with testing and to improve the scripts!

Darrell