Another issue with the existing script is no method is used to determine the KDEDIR location. That variable might or might not be defined whenthe script is executed. For internal purposes of the script, using kde-config is not possible because although /opt/trinity is the default installation location, that is not a certainty. My updated script provides a simple detection method to determine the $PREFIX/bin directory location.

Created attachment 148 [details]
Diff of my proposed script and the 3.5.13 version

Patch attached in addition to the full script.

My version also includes cleanup of KDE/TDE typos and such. :)

Created attachment 149 [details]
Full script of my proposed changes.

Created attachment 194 [details]
Updated patch

Added some more tweaks to startkde, such as adding a test to source xprofile and to set KDEROOTHOME regardless of user id. Setting KDEROOTHOME in startkde is a last resport to ensure kdesu can find root's profile directory. Refer to bug report 393 for full details.

I completely removed the snippet for setting KDEDIRS. In my first patch I only commented out the lines. But the code should not be in startkde. First, adding /usr to KDEDIRS raises havoc when KDE 4 is installed because that is the default installation for KDE 4. Second, KDEDIRS is a user-defined variable. If admins want that variable set then do that some place other than startkde.

Created attachment 195 [details]
Updated full startkde script.

Refer to my comments for the updated diff patch.

> # I think adding this is a good idea.
> if [ -r /etc/xprofile ]; then
>   source /etc/xprofile
> fi
> if [ -r $HOME/.xprofile ]; then
>   source $HOME/.xprofile
> fi


gdm takes care of it in /etc/gdm/Xsession.
I think it must go in /etc/trinity/kdm/Xsession.

gdm takes care of it in /etc/gdm/Xsession.
I think it must go in /etc/trinity/kdm/Xsession.

Some people start X from the command line (starx) rather than trhough a graphical login manager.

Is there a way to test whether the scripts have already been sourced?

(In reply to comment #7)
> Some people start X from the command line (starx) rather than trhough a
> graphical login manager.

/etc/X11/xinit/xinitrc ?
A script in /etc/X11/Xsession.d/ ?

Maybe that's distro-specific and TDE could provide different choices here:
informations, examples...

But from what I've seen about the xprofile file, it's sourced by desktop managers (KDM, GDM, LXDM...) in configurations files (.../Xsession).
If it goes in startkde, there is a great risk that those files, when they exist, will be sourced twice.

> Is there a way to test whether the scripts have already been sourced?

The information isn't stored.
 
But the included script itself could be protected against misconfiguration:

# begin /etc/xprofile
[ ! $ETCXPROFILE ] && {
  export ETCXPROFILE=1

  # content of /etc/xprofile here

}
# end /etc/xprofile

Created attachment 202 [details]
Proposed full startkde script

I split the code for migrating an existing KDE3 profile directory into a separate script named migratekde3. Refer to bug report 709.

The startkde now contains a test to run migratekde3 if that script is found and executable. However, I left that snippet commented out. In the migratekde3 script I added commentary raising the question about whether that script should be run from within startkde. The migratekde3 script is interactive and running from within startkde requires KDialog.

I removed the TDE version number from the very top of the startkde script because the version is always forgotten when a new TDE release is available and that regular oversight looks unprofessional. So let's just forget the version number. The startkde script itself runs a simple test of the TDE version and sends that information to stdout. :)

As before both a full script and a patch are provided.

Created attachment 203 [details]
Updated patch/diff of proprosed startkde script.

Created attachment 251 [details]
Updated diff

I updated the startkde (starttde) script. I uploaded a new diff and a full script.

I removed the previous diffs.

Created attachment 252 [details]
Updated full script

*** Bug 741 has been marked as a duplicate of this bug. ***

Created attachment 285 [details]
Updated diff between 3.5.13 startkde and R14 starttde

Update includes required changes from renaming project (twin, tdeinit, environment variables, etc.)

Created attachment 286 [details]
Updated full script between 3.5.13 startkde and R14 starttde

Update includes required changes from renaming project (twin, tdeinit, environment variables, etc.)

Created attachment 319 [details]
Updated diff between 3.5.13 startkde and R14 starttde

Created attachment 320 [details]
Updated full script between 3.5.13 startkde and R14 starttde

Nominal editorial changes: changed "[starttde]" to "starttde:" to provide a consistent look with other TDE app messages in the xsession log.

Script updated in GIT hash 39fcb49.

I took the liberty of reintroducing the [starttde] message notation, as I personally find it cleaner and easier to read, and would prefer to update the other programs/scripts to use the bracket notation if consistency is needed.

This needs to be THOROUGHLY tested on all distros; I will take care of Ubuntu testing but obviously potential breakage needs to be monitored on systems such as RHEL and Arch.

Thanks for working on this script!

"... would prefer to update the other programs/scripts to use the bracket notation if consistency is needed."

That would be nice. I realize we can't do anything about the non TDE apps, but if all TDE apps formatted their stdout and stderr messages the same way then that would show a high level of attention to detail. :)

I think introducing the changes now will provide ample time for testing on all distros. I'm sure a few tweaks and If/Then tests will be needed to work around various distro quirks.

Several of the changes focus on avoiding KDE4 conflicts. TDE developers and packagers really need to start testing TDE while KDE4 is installed. As a team I don't think we have done a good job of that. :(

If XDG_DATA_DIRS XDG_CONFIG_DIRS or not set, the starttde sets the paths only to their folders, but not to the system folders. As a result, in the menu is missing many items (such as LibreOffice, Gimp, Iceweasel,...) and some items are missing icons.

Created attachment 430 [details]
Add system folders to empty XDG_*_DIRS

Created attachment 431 [details]
Add system folders to empty XDG_*_DIRS

Should starttde be responsible for populating the TDE menu?

My KDE3 system populates the KDE Menu with non KDE3 apps. My Trinity system does not. I don't have XDG_DATA_DIRS set anywhere in my KDE3 environment, before or after starting KDE3. As Trinity is not populating non Trinity apps then something else is preventing that and not starttde.

Additionally, on my Trinity system adding /usr/share to XDG_CONFIG_DIRS and XDG_DATA_DIRS does not help include non Trinity apps to the TDE menu.

Possibly the code is limited to searching only $PREFIX/share and is ignoring /usr/share. We've seen other problems associated with installing Trinity in a location other than /usr.

Ignoring the tqt layer, I notice nothing unique in kstandarddirs.cpp/h between 3.5.10 and Trinity. Some time ago code was added (tdelibs/kio/kio/kservice.cpp) to distinguish Trinity and KDE4 app names in the TDE menu. Perhaps that code inadvertently ignores /usr/share.

(Odpověď na komentář #23)
> Should starttde be responsible for populating the TDE menu?
> 
> My KDE3 system populates the KDE Menu with non KDE3 apps. My Trinity system
> does not. I don't have XDG_DATA_DIRS set anywhere in my KDE3 environment,
> before or after starting KDE3. As Trinity is not populating non Trinity apps
> then something else is preventing that and not starttde.
> 
> Additionally, on my Trinity system adding /usr/share to XDG_CONFIG_DIRS and
> XDG_DATA_DIRS does not help include non Trinity apps to the TDE menu.
> 
> Possibly the code is limited to searching only $PREFIX/share and is ignoring
> /usr/share. We've seen other problems associated with installing Trinity in a
> location other than /usr.
> 
> Ignoring the tqt layer, I notice nothing unique in kstandarddirs.cpp/h between
> 3.5.10 and Trinity. Some time ago code was added (tdelibs/kio/kio/kservice.cpp)
> to distinguish Trinity and KDE4 app names in the TDE menu. Perhaps that code
> inadvertently ignores /usr/share.

I prepared a patch starttde/startkde for backporting to 3.5.13. With the current version of startkde I have other applications in the menu. After the update by #675 applications from the menu disappeared.

So I noticed a different behavior in settings XDG_*_DIRS. The current version of startkde adds not only your folder but always a system folder. The new version of startkde varies according to the current content XDG_*_DIRS, but never adds the system folder.

With my patch other applications appeared again in the menu.

Created attachment 458 [details]
Updated patch to fix /usr/share detection and add fixes for other bug reports.

I found the cause of the problem. The problem is the explicit declaration of $XDG_DATA_DIRS. Specifically, the manner in which $XDG_DATA_DIRS is exported.

In my KDE3 setup, $XDG_CONFIG_DIRS is set in my environment but not $XDG_DATA_DIRS. Yet my KDE3 menu shows non KDE3 apps. However, I have KDE3 installed in /usr, which is the standard installation location. Therefore I don't need to explicitly declare $XDG_DATA_DIRS.

After further experimenting, I realized the problem is the explicit declaration of $XDG_DATA_DIRS. One solution seems as simple as not explicitly setting $XDG_DATA_DIRS in the environment, which was the case with KDE3 too.

Yet remember that traditionally KDE3 is/was installed to /usr and not /opt. The reason this practice of explicitly setting $XDG_DATA_DIRS was started is because Trinity is installed in a nonstandard location other than /usr.

The starttde script needs a more robust test. When Trinity is installed in /usr then $XDG_DATA_DIRS should not be set at all. When Trinity is not installed in /usr, then explicitly setting the $XDG_DATA_DIRS variable is required to find the non standard /opt locations, but also means ensuring the standard /usr/share location is in that path too.

That is, the system always looks in /usr/share for XDG Data files --- except when $XDG_DATA_DIRS is explicitly declared. Then any explicit declaration overrides the default search paths, which in the current starttde script does not include the standard /usr/share location. Therefore when /usr/share is not added as part of $XDG_DATA_DIRS those directories are no longer searched.

Because /usr/share is the default location for $XDG_DATA_DIRS, /usr/share should be placed first in any explicit declaration of $XDG_DATA_DIRS.

The starttde script also fails because $TDEDIR/etc/xdg is searched rather than /etc/trinity/xdg. $TDEDIR/etc/xdg is unlikely to exist.

In summary, when explicitly declaring $XDG_DATA_DIRS, then adding /usr/share is technically correct, but needs a more robust test before explicitly setting $XDG_DATA_DIRS.

I am attaching a proposed patch to fix this. The patch also includes fixes for bug reports 828 and 879. I have tested the patch but not with any exhaustive test plan.

Tim,

I don't want to push this patch to GIT without a peer review. Please peer review and when satisfied, push to GIT.

I'll push to GIT if you're satisfied. I still prefer a peer review. :)

(Odpověď na komentář #27)
> I'll push to GIT if you're satisfied. I still prefer a peer review. :)

Please, /opt/trinity/etc/xdg in R14 was moved to /etc/trinity/xdg?

The location of the Trinity XDG files is defined by the $SYSCONFDIR environment variable. Most people define that location as /etc/trinity, in which the xdg subdirectory gets built.

The TDESetupPaths.cmake files default to installing XDG menu files to ${SYSCONF_INSTALL_DIR}/xdg/menus.

I don't like this part:
"# Caution: This snippet will not accomplish the intent when $SYSCONFDIR != /etc/trinity."

At the very least /etc/trinity and any other candidates (/opt/trinity/etc?) should be scanned for existence, and the affected code should be disabled if no candidates exist.

Also, are the sed strings now repaired?  I remember something on the mailing list regarding corner case breakage.

Created attachment 462 [details]
Updated patch to address concerns in comments.

Patch updated to address several possible xdg directory locations. If none are found, then XDG_CONFIG_DIRS is not updated nor exported. These specific changes also address the location of $SYSCONFDIR, which is unknown to the starttde script (Comment 28).

As the comments in the starttde patch indicate, XDG_DATA_DIRS is updated and exported only when Trinity is installed anywhere other than /usr. In that case, XDG_DATA_DIRS also includes /usr/share.

Regarding the corner cases of /usr/bin, I updated to the best of my understanding of the problem. Look at @@ -152,44 +142,90 @@ to see what I did. Let me know whether that addresses the problem.

I added some nominal changes in the patch to improve portability (bashisms: -n and -z).

Created attachment 463 [details]
Fix the start as the default session

The updated startkde script for determining the TDE path use $0. But if the session is running as a "default", then $0 instead of /opt/trinity/bin/starttde returns /usr/bin/x-session-manager, from which starttde does not detect anything useful.

Therefore, I prepared a patch that adds readlink for canonization.

Comment on attachment 463 [details]
Fix the start as the default session

Attachment 463 [details] committed to GIT in hash d45b921

OK, I went ahead and committed the main patch to GIT in hash 287ead0.  Please rebuild and check for ANY new breakage in TDE; if any is found please report it here.

Please, while component $TDEDIR/bin to your PATH is marshaled sensitively, $TDEDIR/games is roughly thrust to the beginning of your PATH. It probably is not good?

(In reply to comment #37)
> Please, while component $TDEDIR/bin to your PATH is marshaled sensitively,
> $TDEDIR/games is roughly thrust to the beginning of your PATH. It probably is
> not good?

Reopening.

Darrell, can you address the concerns of Slávek above?

Done. Patch merged in GIT hash ae7ec527b7377ae5b2e25be41a86b55fc6a9dc7d.

The same path logic used for $TDEDIR/bin is now used for $TDEDIR/games. Tested here and when the directory exists, $TDEDIR/games now appears in the search path just before /usr/games and no longer at the beginning of the $PATH variable.

Created attachment 464 [details]
Three conditions in one

If he were interested, I have a variant that three tests combined into one expression.

Tim,

I won't claim to be a regex wizard --- not even close. I need help to understand the proposed change. In that light, my concern is whether the code is understandable by non geeks. Perhaps that is unimportant --- I don't know. :)

I'll push to GIT if you (Tim) agree with the proposed change.

(In reply to comment #41)
> Tim,
> 
> I won't claim to be a regex wizard --- not even close. I need help to
> understand the proposed change. In that light, my concern is whether the code
> is understandable by non geeks. Perhaps that is unimportant --- I don't know.
> :)
> 
> I'll push to GIT if you (Tim) agree with the proposed change.

I'm not a regex expert either, though I have written some pretty nasty regexps for tqt.  That being said, I think I see what he is doing, and it looks sane.  I say go ahead and commit it.

The regex patch seems to work here. :)

Pushed in GIT hash 30a104067d53f6f21346dad378fe4fb90c790167.

Thanks!

Created attachment 465 [details]
Fix [: 76: =: unexpected operator

Small one-line fix

Yup, I caught that typo too. Pushed to GIT in hash 28638350377bd6e208c9299b2ebf27190665b947:

http://www.trinitydesktop.org/patches/1331072079:28638350377bd6e208c9299b2ebf27190665b947.diff

At least we both were paying attention. :) Thanks!

Created attachment 527 [details]
Patch to ensure $TDEDIRS is parsed correctly to $XDG_DATA_DIRS

Currently starttde provides no mechanism to ensure $TDEDIRS (not $TDEDIR) is included in the $XDG_DATA_DIRS environment variable. Ths patch provides such a mechanism and provides appropriate commentation.

When $XDG_DATA_DIRS is not explicitly defined, then Trinity uses $TDEDIRS as expected. When $XDG_DATA_DIRS is explicitly defined, then Trinity ignores $TDEDIRS. This patch enssures that does not happen.

Patch to ensure $TDEDIRS is parsed correctly to $XDG_DATA_DIRS was reviewed Slávek Banko (Attachment 527 [details]).

The patch was further updated to test for $MANPATH before appending that environment variable.

Merged upstream in GIT hash 398ef116.

Created attachment 533 [details]
Fix setting MANPATH

MANPATH is not only independent variable. He has a relationship with the configuration file /etc/manpath.config - see: man manpath

Instead in the variable MANPATH must be searched in the result of call 'manpath'.

MANPATH support method changed in GIT hash a664aa0e.

Thanks!

Created attachment 534 [details]
Fix bashism with KDEDIRS parsing

Created attachment 535 [details]
Fix bashism with TDEDIRS parsing

Bashism patch updated in GIT hash 1bd6166b.

As all starttde issues have been addressed, each new issue is being addressed promptly, and this bug report remains open as a continual tracking mechanism, I am bumping down the report to Major status.

As you know, I carefully backporting startup script changes into 3.5.13. Change location /opt/trinity/bin in PATH but led to an interesting error with SAK. If /opt/trinity/bin in PATH is not at the first place, secure dialog from desktop is not working. SAK before signing up works, SAK before unlocking the session works. Only the SAK dialog from the desktop does not work. When I return /opt/trinity/bin int PATH at the first place, it will work!

In R14 you do not have this problem?

Tim and I just finished doing some extensive testing on SAK issues. I haven't seen any quirks like that. I am using the stock starttde.

That is not to say the problem is invalid --- only that I never saw anything like that. Possibly this is isolated to 3.5.13?

To resolve this issue with the KVirc I wanted to use $TDEDIR, but I noticed that it is not exported. It probably is not the intention?

In the starttde script is:
if [ "$TDEDIR" = "" ]; then
  export TDEDIR=`echo "$TDEDIRS" | sed -e 's/:.*//'`
fi

This would TDEDIR exported (indeed, this way it exported in startkde 3.5.12 and earlier). But the script is now set TDEDIR at the beginning == condition is never satisfied. In addition, the script has not set TDEDIRS, so the code would not work properly either.

One last observation: In the 3.5.12 and earlier was KDEDIR including the final slash. But now it is without him. It can not bring complications somewhere?

TDEDIR gets defined at the very beginning of starttde. If that definition is not possible then the script aborts. Therefore TDEDIR is known throughout the remainder of the script and that snippet no longer serves any purpose.

Please, could we avoid adding more "sed" commands to this script ? My eyes are bleeding ...
There are bash built-in string functions which work very well ..

E.g: 

if [ -z "$TDEDIR" ]; then
  export TDEDIR="${TDEDIRS%%:*}"
fi

In general, you should never write something like "echo | sed", "echo | grep" or "echo | awk", or even "echo | anything", there is always a better way to do...

(Odpověď na komentář #57)
> TDEDIR gets defined at the very beginning of starttde. If that definition is
> not possible then the script aborts. Therefore TDEDIR is known throughout
> the remainder of the script and that snippet no longer serves any purpose.

Darrell,

I think I described it wrong. It is not essential that the condition is no longer wasted - can be removed. The point is that the script does not export TDEDIR:

In TDE 3.5.12 (and previous):
$ echo $KDEDIR
/opt/trinity/
$

Now:
$ echo $TDEDIR

$

Created attachment 600 [details]
Adding export TDEDIR

But the latter remains a (potential) problem:

In TDE 3.5.12 (and previous):
$ echo $KDEDIR
/opt/trinity/
$

Now with the patch:
$ echo $TDEDIR
/opt/trinity
$

In the 3.5.12 and earlier was KDEDIR with the trailing slash. But now it is without him. It can not bring complications somewhere?

Please feel welcomed to modify starttde as necessary. Please patch as necessary. :-)

Regarding methods other than piping through sed: I'm always ready to learn new techniques. I never ran across the "%" method before. Is that method portable across the different shells and older bash versions? Where is that technique described in the man page?

I think that generally we try to avoid bashisms in starttde. Is the "%" method bash only?

Regarding TDEDIR not being exported. Curious nobody noticed before. :-) With that said, I just checked and the original 3.5.10 startkde script never exported the variable either. KDEDIR is not defined at all in the 3.5.10 startkde script. I think the presumption then was the variable was defined by the user somewhere, such as with profile.d scripts.

The trailing slash: I don't know whether the difference causes problems.

Export patch pushed to GIT in hash 68be838d.

(Odpověď na komentář #55)
> Tim and I just finished doing some extensive testing on SAK issues. I haven't
> seen any quirks like that. I am using the stock starttde.
> 
> That is not to say the problem is invalid --- only that I never saw anything
> like that. Possibly this is isolated to 3.5.13?

I confirm - it was specific to 3.5.13. Problem found and resolved.
To updates for 3.5.13 added:

commits fb4308f0, e8e118e2
Update kdesktop.desktop file to fix kdesktop tsak integration

Created attachment 630 [details]
Fix path to libnspr, optimize path clipping from TDEDIRS

Marvin L Jones drew attention to a trivial error in the path to libnspr: /usr/libnspr4.so × /usr/lib/libnspr4.so. I also optimized the path clipping from TDEDIRS - use build-in shell functions (tested in bash and dash) instead of "echo | sed". If no objections, I will push it into the GIT.

Created attachment 631 [details]
Fix path to libnspr, optimize path clipping from TDEDIRS, fix PRELINKING condition, fix TDE_SESSION_UID

To correct path to libnsrp and optimizing path clipping from TDEDIRS I have added correction a small thing in testing PRELINKING and second way to set TDE_SESSION_UID - on my machine during starttde is $UID empty, and thus TDE_SESSION_UID remained empty. Or should I use `id-u` as the only one way to set TDE_SESSION_UID?

Fixed in GIT hash f70bd6c7.

Darrell,

I wanted to find out why the programs fall if is installed kgtk. So I prepared a patch for kgtk to does not start function that not find (ie, a null pointer).

Then I discovered that in starttde setting LD_PRELOAD is strange. LD_PRELOAD is always set to be kgtk but regardless of what the program is run - GTK, QT, everything. Of course it does not find desired functions for QT programs in GTK library.

The question therefore arises whether it is even possible to have in starttde such LD_PRELOAD? Is there a universal wrapper that could distinguish whether to use or kgtk kqt?

Looks like the code snippets for kgtk dialog support and LD_PRELOAD were first added here:

http://git.trinitydesktop.org/cgit/tdebase/commit/starttde?id=b3e920373e396a5af2d3f39c6e3ae51fe01b92a9

I don't know how LD_PRELOAD works in detail. There were no LD_PRELOAD exports in the 3.5.10 startkde.

A quick look into the description of kgtk indicates the package is based upon using LD_PRELOAD. The concept seems to be based upon using a wrapper script to run certain gtk apps. Seems to me this wrapper script is where the LD_PRELOAD variable should be set.

Looking at the wrapper scripts indicates LD_PRELOAD is set in those scripts. The README implies that the wrapper scripts handle the LD_PRELOAD requirement. I'm inclined to think setting LD_PRELOAD in starttde is not required because then LD_PRELOAD is set globally for the user's entire session, but Tim probably should answer those related questions.

Although I build the kgtk dialog package to watch for build issues, I don't use kgtk dialog. Provide some steps for me to duplicate that demonstrates the problems and I'll help test.

(Odpověď na komentář #68)
> Looks like the code snippets for kgtk dialog support and LD_PRELOAD were first
> added here:
> 
> http://git.trinitydesktop.org/cgit/tdebase/commit/starttde?id=b3e920373e396a5af2d3f39c6e3ae51fe01b92a9
> 
> I don't know how LD_PRELOAD works in detail. There were no LD_PRELOAD exports
> in the 3.5.10 startkde.
> 
> A quick look into the description of kgtk indicates the package is based upon
> using LD_PRELOAD. The concept seems to be based upon using a wrapper script to
> run certain gtk apps. Seems to me this wrapper script is where the LD_PRELOAD
> variable should be set.
> 
> Looking at the wrapper scripts indicates LD_PRELOAD is set in those scripts.
> The README implies that the wrapper scripts handle the LD_PRELOAD requirement.
> I'm inclined to think setting LD_PRELOAD in starttde is not required because
> then LD_PRELOAD is set globally for the user's entire session, but Tim probably
> should answer those related questions.
> 
> Although I build the kgtk dialog package to watch for build issues, I don't use
> kgtk dialog. Provide some steps for me to duplicate that demonstrates the
> problems and I'll help test.

You mentioned commit performed only renaming - kgtk was added from a much earlier:
http://git.trinitydesktop.org/cgit/tdebase/commit/startkde?id=579cae43096d461bfcd5709aa2d5f37963096952

For the first time it is already in 3.5.12. I'll try to test whether it had been so devastating in 3.5.12.

I can confirm: If is set LD_PRELOAD, also on 3.5.12 "anything" falls.

Exactly what fails?

How do I reproduce?

What happens when LD_PRELOAD is not exported from within starttde?

(Odpověď na komentář #71)
> Exactly what fails?
> 
> How do I reproduce?
> 
> What happens when LD_PRELOAD is not exported from within starttde?

Just install kgtk-qt3 and it is not possible even logged into the Trinity. Crashes xsetroot, dcopserver ... anything that needs to call dlsym. When commented out "export LD_PRELOAD" everything works again.

I understand that we will need to enter a separate bug for kgtk. Now just do not know what to do with LD_PRELOAD in starttde - when is potentially dangerous?

I can't replicate the problem.

Possibly I am not correctly building the package because I do not have a $TDEDIR/share/kgtk directory. According to the script logic, that means on my system $TDEDIR/share/kgtk/preload does not exist, which means TGTK_PRELOAD never gets set, which means LD_PRELOAD never gets exported.

Looks like I'm building correctly. The preload problem seems to be Debian (notice the last lines of the build script):

http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/maverick/applications/kgtk-qt3/debian/rules

I don't know why this is needed in Debian.

(Odpověď na komentář #74)
> Looks like I'm building correctly. The preload problem seems to be Debian
> (notice the last lines of the build script):
> 
> http://git.trinitydesktop.org/cgit/tde-packaging/tree/ubuntu/maverick/applications/kgtk-qt3/debian/rules
> 
> I don't know why this is needed in Debian.

Interesting. So just to Debian is kgtk preload so universally used. So much universally, that it leads to unusable. The question thus arises: throw that part of starttde? For Debian is a "fatal" and for the other distributions is unnecessary.

You and Tim will have to discuss that. :-)

As I mentioned in comment 68, the wrapper script already use the LD_PRELOAD environment variable. I don't what role kgtk/preload plays in this.

A quick test of the kgtk-wrapper script opening Firefox indicates the script works here with Slackware 13.1.

Hello, on distributions using the older man (not mandb), the "manpath" command does not recognize the "-q" argument, so it generates an error message in startkde script.

(Odpověď na komentář #77)
> Hello, on distributions using the older man (not mandb), the "manpath" command
> does not recognize the "-q" argument, so it generates an error message in
> startkde script.

Ok, for better compatibility we can use manpath 2>/dev/null instead of manpath -q. What is your opinion?

Yes, using 2>/dev/null should be fine for everyone.

Compatibility with older manpath fixed in GIT hash 55c88e37

Created attachment 986 [details]
kdebase 3.5.13.1 : fixes paths

Hello, here is a new patch (for 3.5.13.1) that fixes the following issues:

1) Path setting: defines functions based on shell-builtin commands to parse and modify path, instead of complicated ans useless grep|awk|sed|...
BTW, the "bin" and "games" path checking do not work at all currently, due to too much backslashing in "grep" and "sed" commands.

2) Cleans up the $KDEHOME setting, since almost every test case gives the same result => $KDEHOME/.trinity .

3) Fix KDE_VERSION variabe detection so that it works with all KDE3/TDE/KDE4 versions.

Created attachment 1056 [details]
kdebase: fix startkde paths setting

I made three adjustments your patch:
1) path assembled in NPATH always began with a colon
2) to test kde-config was hard-coded /usr/bin, instead of $KDEDIR (ie /opt/trinity/bin)
3) to determine the version of TDE was used bash specific syntax

Please test it in your distribution.
Then I commit patch with your name.

Your latest patch is working as expected for me ..

(Odpověď na komentář #83)
> Your latest patch is working as expected for me ..

I watched yet again to:
2) to test kde-config was hard-coded /usr/bin, instead of $KDEDIR (ie
/opt/trinity/bin)

It seems to me that in reality this test is to verify whether is the Trinity system installed in /usr instead of /opt/trinity. In this case, it would instead of testing /usr/bin/kde-config, which for v3.5.13-sru branch can be confused with the original of KDE3, to test whether "$KDEDIR" = "/usr". What do you think?

I do not understand the actual purpose of all these tests.

Actually, I do not see any case where we would want TDE to use anything else than ~/.trinity .
As soon as we use something else, like ~/.kde , there is a risk that we corrupt a KDE3 or KDE4 user profile... We can not guess if KDE3 or KDE4 is installed at all, even testing /usr is insufficient, for example, in openSUSE KDE3 is installed under /opt/kde3 ...

So I think that we should *always* set KDEHOME=~/.profile , and give the user the ability to migrade ~/.kde or ~/.kde3 to ~/.trinity, it it exists.

(En réponse au commentaire 85)
> So I think that we should *always* set KDEHOME=~/.profile , and give the user
> the ability to migrade ~/.kde or ~/.kde3 to ~/.trinity, it it exists.

Of course I meant ~/.trinity, not ~/.profile .

(Odpověď na komentář #85)
> I do not understand the actual purpose of all these tests.
> 
> Actually, I do not see any case where we would want TDE to use anything else
> than ~/.trinity .
> As soon as we use something else, like ~/.kde , there is a risk that we corrupt
> a KDE3 or KDE4 user profile... We can not guess if KDE3 or KDE4 is installed at
> all, even testing /usr is insufficient, for example, in openSUSE KDE3 is
> installed under /opt/kde3 ...
> 
> So I think that we should *always* set KDEHOME=~/.profile , and give the user
> the ability to migrade ~/.kde or ~/.kde3 to ~/.trinity, it it exists.

Yes, for me also seems better to use always "~ /.trinity". I propose now to apply the patch with test "$KDEDIR" = "/usr" and the question of migration from KDE profile solve separately afterwards.

Related to this is the fact that soon I'll include into v3.5.13-sru branch migratekde3 script.

Comment on attachment 1056 [details]
kdebase: fix startkde paths setting

Pushed to GIT in hash 48724f4b and also into v3.5.13-sru branch.

Created attachment 1134 [details]
startkde: fix XDG_DATA_DIRS variable

Hello, I've found new problems in current startkde script, related to XDG_DATA_DIRS.
Under openSUSE, there are distribution-provided scripts that sets variable XDG_DATA_DIR=/usr/share:/opt/trinity/share BEFORE we actually call startkde.

The result is that startkde does not modifiy the variable at all.
Then, having "/usr/share" before "/opt/trinity/share" in TDE causes undesirable effects, such as having icons not displayed in start menu.

The attached patch does the following:
- Modifies 'is_in_path' and 'place_before_in_path' functions so that they can be used with any variable, not just $PATH.
- Add 'remove_from_path' function.
- Ensures that "/opt/trinity/share" is always BEFORE "/usr/share" in XDG_DATA_DIRS

Created attachment 1135 [details]
startkde: fix XDG_DATA_DIRS variable

Better handles empty variables (avoid strange messages when modifying/searching a variable that is not already set)

I wonder why the OpenSuse folks are setting the XDG_DATA_DIRS variable. We added a lengthy comment in our starttde script about when the XDG_DATA_DIRS variable should be set. Setting the XDG_DATA_DIRS variable is supposed to be an exception rather than the norm.

The KDE folks also incorrectly set the variable in their startkde script, which causes failures with the KDEDIR/KDEDIRS env. variables.

Francois, would you please post the respective OpenSuse script? I will modify for my Slackware setup so I can test the patch. :)

Slavek, this patch is something you should review and push. :)

Created attachment 1136 [details]
/etc/profile.d/xdg-environment.sh script from openSUSE

The attached script is located in /etc/profile.d (and is executable) under openSUSE.
It looks for /opt/*/share directories and put them automatically in XDG_DATA_DIRS, after the default /usr/share value.

Okeydokey. I'll test this.

After updating for R14, I tested the patch.

The patch places /opt/trinity/share first in the XDG_DATA_DIRS string. This overrides the OpenSuse profile.d script, but also overrides any user defined XDG_DATA_DIRS string that includes the TDEDIRS variable. Anybody using the TDEDIRS variable wants and expects that variable to be first in the string.

For those predefining XDG_DATA_DIRS to use the TDEDIRS variable, /opt/trinity/share appears twice in the final XDG_DATA_DIRS string after starting TDE.

I use TDEDIRS like this:

TDEDIRS=/usr/local/tde_mods:/opt/trinity

The purpose of the TDEDIRS variable is to allow users to create files that override the default files located in $PREFIX (/opt/trinity for most of us). That is, the preferred search order changes.

Forcing /opt/trinity/share first in the string before the TDEDIRS variable means the TDEDIRS variable is rendered ineffective.

Somehow the patch is not preserving or restoring TDEDIRS first in the XDG_DATA_DIRS string.

In my environment I should see this before and after starting X:

TDEDIRS=/usr/local/tde_mods:/opt/trinity
XDG_DATA_DIRS=/usr/local/tde_mods/share:/opt/trinity/share:/usr/share

Instead I see this:

XDG_DATA_DIRS=/opt/trinity/share:/usr/local/tde_mods/share:/opt/trinity/share:/usr/local/tde_mods/share:/usr/share

Notice the duplication.

1. We need to eliminate the duplication.

2. We should not tinker with the variable if TDEDIRS is part of the XDG_DATA_DIRS string.

3. In my xsession-errors log, I see the following:

/opt/trinity/bin/starttde: line 22: test: too many arguments, which is occuring from here:

if ! is_in_path XDG_DATA_DIRS $dir && [ -d "$dir/share" ]; then

This is a convoluted corner case and the real problem is really upstream with the OpenSuse folks. Perhaps the better solution is to contact them and ask them to add some sanity checks to their profile.d script.

Created attachment 1137 [details]
starttde: fix XDG_DATA_DIRS variable (patch modified for R14)

Created attachment 1138 [details]
startkde: fix XDG_DATA_DIRS variable (2)

OK here is an updated patch which works as expected (I hope).

Created attachment 1141 [details]
starttde: fix XDG_DATA_DIRS variable (2) (patch modified for R14)

Good job! :)

I updated the R14 patch as well.

On my system, which does not use the OpenSuse profile.d script, the patched starttde does not modify the XDG_DATA_DIRS variable. The variable remains the same before and after starting X.

Works for me, works for you. Probably should let Slavek test beore pushing as he uses both 3.5.13.2 and R14.

Comment on attachment 1141 [details]
starttde: fix XDG_DATA_DIRS variable (2) (patch modified for R14)

Pushed to GIT in hash a733ce41.
Thanks you both for good job.

Comment on attachment 1138 [details]
startkde: fix XDG_DATA_DIRS variable (2)

Cherry-picked into v3.5.13-sru branch.

Created attachment 1191 [details]
startkde: fix KDEDIRS does not contain KDEDIR

Hello, still issues in 3.5.13.2 !
Running CentOS 6, KDE4 installed (under /usr) alongside TDE (under /opt/trinity).
Some "profile.d" script set KDEDIRS to "/usr" before the actual "/opt/trinity/bin/startkde" script.

As as result, the TDE startup scripts sets KDEDIR=/opt/trinity and keeps KDEDIRS=/usr .

The side-effect is that TDE then uses the KDE4's translation files (under /usr/share) and not the TDE ones.

The attached patches ensures that, if KDEDIRS contains "/usr", then "/opt/trinity" is put before it.

This affects only 3.5.13.2, correct? In R14, KDEDIR(S) is renamed to TDEDIR(S) and there should be no such conflict.

Yes, in R14 with TDEDIRS the problem should not exist.

Yes - I am aware of the specificity for v3.5.13-sru branch - I'll push patch from attachment 1191 [details] soon.

Comment on attachment 1191 [details]
startkde: fix KDEDIRS does not contain KDEDIR

Pushed to GIT branch v3.5.13-sru in hash b113c22b

Ha sorry there was a typo in latest patch !

I wrote:
  if is_in_path KDEDIRS "/usr" && ! is_in_path PATH KDEDIRS "${KDEDIR}"; then

But it should have been:
  if is_in_path KDEDIRS "/usr" && ! is_in_path KDEDIRS "${KDEDIR}"; then

The word "PATH" should not be there !

(Odpověď na komentář #105)
> Ha sorry there was a typo in latest patch !
> 
> I wrote:
>   if is_in_path KDEDIRS "/usr" && ! is_in_path PATH KDEDIRS "${KDEDIR}"; then
> 
> But it should have been:
>   if is_in_path KDEDIRS "/usr" && ! is_in_path KDEDIRS "${KDEDIR}"; then
> 
> The word "PATH" should not be there !

Oh, how I integrated the patch quickly, so I also inadequately revise it. Fixed in GIT hash 64ed2efa. Thank you