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