Ho no, it looks like it's caused by the KDEDIRS variable.
$ echo $KDEDIRS
/usr:/opt/trinity/:/usr/:/opt/trinity/:/usr/


I thought this one was only used in 'startkde' to guess the KDEDIR variable (in my case /opt/trinity).
$ echo $KDEDIR
/opt/trinity


I guess I'll have to patch (again) the startkde script to ensure that the KDEDIRS variable begins with $KDEDIR .

Created attachment 224 [details]
Fix directories location in startkde

It looks like a last minute change messed up a bit the startkde 3.5.13 script: string replacements from 'kde3' to 'trinity' gave duplicate and/or incorrect path checking.

This patch suppresses useless tests and ensures that $KDEDIR is put in front of KDEDIRS variable.
Please note that this patch is valid under RHEL/Fedora because there are scripts under /etc/profile.d/ that sets KDE4 variables and XDG variables BEFORE the Trinity startkde script is called. So we do not have to set standard path, like '/usr/share' or '/etc/xdg'.

The patch duplicates efforts in bug 675. KDEDIRS must be in the path before KDEDIR because that is how the variable functions correctly. The KDEDIRS variable must be defined by end-users and not upstream. KDEDIRS is a user defined variable and never should be hard-coded in startkde.

The conflicts noted in this bug report with KDE4 were noted in bug report 675. In bug report 675 the startkde script was patched to remove the KDEDIRS declaration as well as adding some tests before setting other environment variables.

Slackware also uses /etc/profile.d scripts to establish environment variables. Those scripts currently are problematic for TDE users because the variables must exist in a multi-user multi-desktop environment. These problems likely will disappear with the renaming project because environment variables will be renamed too. For example, KDEDIR will be renamed to TDEDIR and KDEDIRS to TDEDIRS. Thereafter there will be no conflict with KDE4 environment variables.

The trick until then is to use KDEDIRS only with directories related to TDE and not other desktops.

Hello, in fact, the attached patch does not solve totally the problem.

It looks like the '/etc/profile.d/kde.sh' script, which sets KDEDIRS, is installed by some KDE4 configuration package.

There are cases where KDE4 applications and/or Gnome applications are installed, but not the KDE4 configuration package. So KDEDIRS does not contain /usr when TDE start ups.

In that case, non-TDE applications (firefox ...) are not visible in the TDE start menu, which is, in my opinion, a problem.

Also, I do not understand why KDEDIR should be guessed from KDEDIRS, since KDEDIRS can contain anything, including bad directories.
In my opinion, it should be the contrary: KDEDIR should always be hardcoded to where TDE is actually installed, and KDEDIRS should be guessed/built by some scripts.

The problem with KDEDIRS will be resolved when the renaming project completes and all environment variables change names, such as KDEDIR to TDEDIR and KDEDIRS to TDEDIRS. There is no easy way to stop other apps from setting the KDEDIRS variable, but the new proposed startkde script in bug report 675 no longer hard-codes that variable.

Until the renaming project is complete, possibly the proposed new startkde script can test whether KDEDIRS is already set. If set, test whether the variable includes KDE4 folders or KDE3 folders and if true, unset the variable.

The alleged problem with non TDE apps not appearing in the menu is solved by using the Menu Updating tool in the T-Menu/System.

Yes, I've already understood the KDEDIRS/TDEDIRS renaming the first time you wrote that, there is no need to repeat in every comment. I also read the mailing list BTW.

For now, if the KDEDIRS variable is used/required by TDE 3.5.13, why should'nt the startup script modify it to the correct value for TDE ?

If you unset KDEDIRS or remove /usr from it, you lose not only the start menu items, but all the translations (and other shared stuffs) for KDE4 applications launched within TDE environment.
And I guess it has others side-effects that I've not seen yet.

About the start menu: I'm using TDE for corporate users. I won't deploy a "broken" configuration (not seeing all apps in start menu), then telling my users "hey, you can fix it yourself by opening a tool and clicking on some items". In fact, I'm not even sure that users are allowed to use the start menu editor ...
Everything *must* work out of the box (at least for newly created user profiles).

So, I think the "best workaround" for TDE 3.5.13 is to always add /opt/trinity first in KDEDIRS.

You can handle KDEDIRS any way you want. The variable is intended to be user-defined. :) To satisfy my own preferences I have been modifying startkde for many years. :)

A challenge with KDEDIRS including /usr is on systems with KDE4 installed. When that is the case, the apps located in /usr/share/autostart, which mostly will be KDE4 apps, will start in the TDE environment, which for most people is not wanted.

If you do not have KDE4 installed then including KDEDIRS in startkde probably is doable.

A challenge with hard-coding KDEDIRS in startkde is the people who already have that variable pointed to their own preferred location get clobbered by the startkde script. There are people who do not want KDEDIRS defined at all. Hard-coding is not a good idea because the variable is intended to be user-defined.

People who use distros that support /etc/profile.d get around the problem by defining KDEDIRS there. I don't know a palatable solution for distros that don't use that directory.

The problem with non TDE apps not appearing in the menu probably is an XDG environment variable problem. We probably need to add some more options in the startkde script to ensure those apps get seen by TDE. Yet again the problem of having KDE4 installed will cause the T-menu to get cluttered with KDE4 apps. The TDE devs cleverly devised a way to distinguish TDE and KDE4 apps with the same name, but menu clutter is still the result. If KDE4 is not installed then this is not an issue, but TDE devs can't control or predict when KDE4 is installed and have to presume KDE4 is installed. In a true multi-user environment where users are allowed to choose their desktop environments, KDE4 likely will be installed.

The proposed startkde is just that: proposed. The default startkde that came with 3.5.13 causes problems for many people. The script needs attention and solid testing to be flexible for many distros. Please help with updating the script. I do a lot of TDE usability testing and likely will test any changes you offer with startkde.

If you are using TDE in a enterprise environment, I'm sure most of the devs want to hear your experiences in the mailing list. I'm not a dev, just a packager and all-around usability tester, but I certainly would like to hear your experiences with TDE in that environment.

Marking as duplicate of bug 675 as KDEDIR* has been renamed to TDEDIR* in R14.0, and the remaining issues mentioned in this report should be addressed in the master startkde update/repairs bug.

*** This bug has been marked as a duplicate of bug 675 ***