> Looking at the tdelibs/tdecore/kstandarddirs.cpp > locations, I noticed the KDELIBSTUFF is hard coded to /trinity /trinity/plugins for > module and qtplugin types. I've wondered why that wasn't /tde and /tde/plugins > since it replaces /kde /kde/plugins. Is there a way to pass an environment > variable or something similar to the file so that the following code: > > TQString KStandardDirs::kde_default(const char *type) { > <snip> > if (!strcmp(type, "lib")) > return "lib" KDELIBSUFF "/"; > if (!strcmp(type, "module")) > return "lib" KDELIBSUFF "/trinity/"; > if (!strcmp(type, "qtplugins")) > return "lib" KDELIBSUFF > "/trinity/plugins"; > <snip> > > could do something like: > > TQString KStandardDirs::kde_default(const char *type) { > <snip> > if (!strcmp(type, "lib")) > return "lib" KDELIBSUFF "/"; > if (!strcmp(type, "module")) > return "lib" KDELIBSUFF "/tde/"; > if (!strcmp(type, "qtplugins")) > return "lib" KDELIBSUFF > "/tde/plugins"; > <snip> > > What I don't have a feel for is how the hard coded > /trinity location trickles through the rest of the code. If it is relied on by much of > the rest of the build, it isn't worth fixing, but hard coding the location > seems like it could lead to issues later. Just a stray thought. Please refer to bug report 892. Although I have had progress patching packages to the correct XDG information, I have problems evry time I change the path to applications/tde. Everything I have tried results in everything installing to that new location, but experiencing breakage in apps. Something somewhere in the code is cleverly hidden or hard-coded to look for applications/kde. If I could resolve that problem I could start pushing all of the related package patches to fix all of the XDG related files (mostly *.desktop files, but some stray code too). This bug report and the help files are biggies. I'm starting a new build run this evening to run overnight and through that I'll create the necessary patches for the help files. Darrell