Recently Trinity/TDE was added to the list of registered desktop environments: http://standards.freedesktop.org/menu-spec/latest/apb.html. Before that event I have been developing a related patch set. I'm about to push this large patch set, which affects XDG compliance and will help avoid potential conflicts with KDE4. The patch set is an effort to resolve bug report 892.
Almost every module is affected.
The patch set performs the following:
* Updates all occurrences (*.desktop files and source code) of X-KDE-* to X-TDE-*
* In *.desktop files, updates KDE; -> TDE; in all Category keys
* Renames $TDEDIR/share/applications/kde -> $TDEDIR/share/applications/tde
Resolving bug report 892 is important to R14. I have tested the patch set about as far as I can go. The time has arrived for additional eyes to help spot possible remaining bugs. :-)
I am not blindly pushing this patch set. I have been testing the patches for a long time and have been focused on looking for breakage with daily usability testing. Making these global changes has taken me a long time to test. Overall I'm pleased with the effort and excepting possible bugs, I think everybody in the Trinity community will be pleased too.
Do I expect breakage? The conservative answer is probably. No person is capable of knowing every conceivable usage of Trinity. I have tried to be as diligent as possible with my testing, but I don't use every single Trinity feature --- I'm not even aware of them all :-). There is a likelihood I missed something.
With that said, when testing from GIT be sure to use the patched starttde. If you use your own customized starttde, then you need to know where your profile will break. Profile breakage is guaranteed if you don't use the patched starttde, or you don't backport the patch to your customized starttde. Trinity will load and run but oddball things happen when the profile is not updated to match the patch set.
When using the patched starttde there should be no profile problems because starttde updates the profile. This update process is a one-time event and is recorded in kdeglobals. In my testing I did not notice any slowdown in starttde caused by this one time event. Possibly those people with significantly large profiles might see a one-time delay, but probably no more than a few seconds.
I do not claim to being a shell script wizard. I welcome any starttde patching improvements.
Please do not attempt to backport this large patch set to 3.5.13. Please do not attempt to backport the related starttde patches to 3.5.13. These changes are for R14 [DEVELOPMENT] and forward. Backporting will cause breakage.
Known challenges with developing the patch set:
* Update user's profile starttde will update profile *.desktop files
* User-defined keyboard shortcuts break starttde will update shortcuts
* User-defined file associations are ignored starttde will update profilerc
* Sym links to $TDEDIR/share/applications/kde break and must be relinked -> $TDEDIR/share/applications/tde starttde will fix sym links in Autostart NOTE: starttde does NOT fix non profile sym links
* One issue I can't update because root permissions are required to fix, but when using $TDEDIRS, be sure to rename $TDEDIRS/share/applications/kde -> $TDEDIRS/share/applications/tde. Clues include duplication in the TDE menu. Notice I refer to $TDEDIRS and not $TDEDIR.
I tested the patched starttde against a current Trinity profile, a kde3 profile, and a 4-month old profile. All updated as expected.
GIT Testing:
* Please make a backup of your $TDEHOME profile directory.
* The backup profile will help troubleshoot bugs in the patched starttde by providing a convenient way to restore the old profile and retesting.
* The first time the patched starttde runs, as explained there will be some updating of profile files. When the update process completes, starttde will stamp $TDEHOME/share/config/kdeglobals:
[R14 XDG Updates] Updated=true
* If you find odd things happening, exit the session, delete those two lines from kdeglobals or change the key to false and start TDE again. This will force the patched starttde to run the updates again.
* Report any related bugs to the developer's mail list or in bug report 892.
* Ignoring bugs, the entire patch set and profile updates should be transparent to users. Users should not notice anything.
I will push this patch set in two phases. First, because I have been building and testing the patches outside of my local GIT repository, I'm going to merge those patches with my local tree and run a full build set. That will take most of the day. Then after verifying no obvious build or usability issues, I'll push the patches to the central GIT repository.
I will post another message to the list when I start pushing upstream. Otherwise building from the GIT tree during that period will create some strange results, not in building, but usability. :-)
Basically I'm posting now as a forewarning. :-)
This is a large undertaking, hence my post before pushing the patch set. This patch set is needed one way or another. The sooner we push the sooner we all can test, which is the nature of the GIT sources. I am not expecting traumatic failures because I have been using a patched Trinity in daily usage. Nonetheless, thank you everybody for your patience and confidence!
Darrell
On 06/07/2012 02:58 PM, Darrell Anderson wrote:
This is a large undertaking, hence my post before pushing the patch set. This patch set is needed one way or another. The sooner we push the sooner we all can test, which is the nature of the GIT sources. I am not expecting traumatic failures because I have been using a patched Trinity in daily usage. Nonetheless, thank you everybody for your patience and confidence!
Darrell
Push away - we'll build when we get it and throw rocks at you after that :)
First phase looks good. All patches seemed to have merged to my GIT tree without incident and I'm not noticing any usability issues. :-)
I'll start pushing the full patch set today. This will take a while --- a 100+ module comments to copy, paste, and push. There probably is a way to automate this, but I probably would find a way to make a mess. :-)
Be forewarned that until I complete the full push that trying to use the GIT sources during this period will create oddball results in usability, although everything will build. Probably best to wait until tomorrow to update local source trees.
I'll try hard to finish as soon as possible because some of you like to run nightly builds (although night time in one part of the world is day time in another :-) ).
This tape will self-destruct in 15 seconds....
Darrell
I pushed the full patch. I hope I did not miss any pushes. As a test I'm going to rsync my local tree and start a new full rebuild.
This is a massive update --- I'll try to stay close to the email for the few days.
Upon discovering breakage, please don't throw rocks --- throw Nerf balls. :-)
Darrell
On 06/08/2012 06:05 PM, Darrell Anderson wrote:
I pushed the full patch. I hope I did not miss any pushes. As a test I'm going to rsync my local tree and start a new full rebuild.
This is a massive update --- I'll try to stay close to the email for the few days.
Upon discovering breakage, please don't throw rocks --- throw Nerf balls. :-)
Darrell
Pulling everything now....