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
All,
Running kmenuedit from the command line, I received the following:
15:05 valkyrie:~> kmenuedit
15:05 valkyrie:~> libpng warning: Interlace handling should be turned on when
using png_read_image
Is that something that needs to be addressed? Or, is that just a message that
can be turned on/off?
--
David C. Rankin, J.D.,P.E.
I'm looking for breakage with a patch set for bug report 892. In that testing I tried to play twin4, a Connect Four type game.
The game is broken here.
All I'm asking is for somebody who is using GIT packages to test whether the game works.
Select one of the arrows in the top row to insert a disk in a column. That's all. :-)
The game is listed as kwin4 in the TDE menu (Games/Board games). I have a patch for those branding issues.
Thanks!
Darrell
A while ago we updated several wallpaper svgz images. How did we do that --- what software was used?
I updated several png images in GIT hash 49c4ccfe to fix some branding. I would like to update a related svgz, but I don't how.
The specific file to update:
tdebase/kcontrol/pics/crsc-app-background.svgz.
View tdebase/kcontrol/pics/cr128-app-background.png in the latest GIT to see how I updated that image. The svgz should look the same.
Thanks!
Darrell
I'm looking for help with reorganizing the TDE menu when TDE and KDE4 menu are installed concurrently.
In a word: clutter.
I'm getting ready to push a huge patch set that will help liberate TDE using our own XDG registrations. That effort will help avoid potential conflicts with KDE4. More to come about that patch set (refer to bug report 892), but the patch is looking very good at the moment.
A while ago I filed bug report 977 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=977). Please read the bug report to understand the goal of moving the KDE4 menu items.
I want to create a separate KDE4 top-level menu and let the KDE4 menu appear there.
Although KDE4 apps are uniquely identified with a "[KDE4]" text marker in the menu (created in tdelibs/kio/kio/kservice.cpp), when TDE is installed concurrently with KDE4 there is nonetheless some serious menu clutter. Moving KDE4 menus to their own location would reduce that clutter. Moving allows TDE to display its own set of apps. Users decide which version of duplicate apps they prefer, but moving the KDE4 menu establishes that the user is running TDE.
I'm thinking with the upcoming patch set that moving the KDE4 menus probably is doable. Now is a good time to test this while I finalize testing for the upcoming patch set.
I have nominally tested adding a <Not><Category>KDE<Category></Not> set to prevent KDE4 items from appearing in a menu category. That removes the KDE4 items from the main TDE menu and reduces clutter.
I'm struggling to get the KDE4 menu to appear by itself in the top level. Basically I want to merge /etc/kde/xdg/menus/applications.menu into the TDE applications.menu.
I appreciate any help.
Thanks!
Darrell
Is anybody installing KDE3 and Trinity concurrently? Specifically, both desktops are installed to the same partition set and as appropriate for the respective distro, users can select between either desktop environment?
This requires installing both desktops in different locations, such as /usr and /opt/trinity, or /opt/kde3 and /opt/trinity.
I run both desktops and use KDE3 often to compare/debug Trinity issues. I do this with a separate installations and virtual machines. I would enjoy being able to install both desktops to the same partition set, but I run into serious menu problems that I haven't resolved. Being able to run one user in Trinity and another user in KDE3 for testing would be much better than using a VM (VMs have some limitations).
Thanks much.
Darrell
Latest GIT.
Would somebody confirm whether the "What's This" tooltips work in KControl?
Simply "right-click" on a check box text string. A popup should appear with the text string "What's This?" and when selected, a tooltip help string appears.
The "What's This" tooltips work correctly when I start a KControl module from the minicli or from the TDE Settings menu. They don't work when I try to use them in the full KControl.
Thanks.
Darrell
