I'm working on bug report 892. Most of this work involves changing XDG categories (X-KDE-Whatever -> X-TDE-Whatever), which will help further distinguish Trinity from KDE3 and KDE4 and reduce potential conflicts. The work is going well but I have run into a challenge.
When I rebuild tdelibs and tdebase to install desktop files to $PREFIX/share/applications/trinity rather than $PREFIX/share/applications/kde, a few things start breaking.
Some keyboard shortcuts stop, but I can recover that by deleting the user's khotkeys config file and starting afresh. That problem might be related or not, or might just be cruft from its KDE3 days when I migrated profiles.
The real problem is noticeable when I open Konqueror and select the Settings menu option. Most of the setting modules do not appear. The only modules that appear are the "native" ones: Behavior, Appearance, Previews & Meta-Data, and Performance.
The associated desktop files built and installed to $PREFIX/share/applications/trinity just fine.
I can solve the problem by creating a sym link from $PREFIX/share/applications/kde to $PREFIX/share/applications/trinity and restarting the session.
I tried a new profile but that did not solve the problem either. Only the sym link, or building to $PREFIX/share/applications/kde, avoids the problem.
I haven't tested with other packages because at this point I only need tdelibs and tdebase for testing.
At this point I'm concluding that something in the code is hard-coded to look for $PREFIX/share/applications/kde. I can't find anything obvious or explicit. I've looked hard and am stumped.
I would appreciate any help in this challenge. :)
Thanks!
Darrell
<snip>
At this point I'm concluding that something in the code is hard-coded to look for $PREFIX/share/applications/kde. I can't find anything obvious or explicit. I've looked hard and am stumped.
I would appreciate any help in this challenge. :)
Thanks!
Darrell
Have you looked through the CMake files? There are a few places where CMake variables are written into TDE via autogenerated #defines.
Other than that the class name you are probably looking for is KStandardDirs, as it stores all search directories. See http://trinitydesktop.org/docs/trinity/current/kdelibs/kdecore/html/classKSt... for documentation.
Tim
Have you looked through the CMake files? There are a few places where CMake variables are written into TDE via autogenerated #defines.
Other than that the class name you are probably looking for is KStandardDirs, as it stores all search directories. See http://trinitydesktop.org/docs/trinity/current/kdelibs/kdecore/html/classKSt... for documentation.
Thanks. I've run through kstandarddirs.cpp several times. I'm running new builds now with and without the change. I'm hoping I will notice a difference in the build logs and cmake cache files.
I have two test environments, one with and one without KDE3 concurrently installed. In the one with KDE3 installed, I renamed /usr/share/share/applications/kde to kde3 and Konqueror would not display all of the setting modules. When I restored that directory name back to kde and restarted the session, Konqueror again displayed the setting modules.
Therefore something in Konqueror or the base system will use /usr/share/applications/kde despite being built to use /opt/trinity/share/applications/trinity.
As I mentioned, when I create a sym link from /opt/trinity/share/applications/trinity -> kde then Konqueror finds all of the modules.
This is true even after editing starttde and my environment to limit XDG_CONFIG_DIRS=/etc/xdg:/etc/trinity/xdg and XDG_DATA_DIRS=/opt/trinity/share and unsetting TDEDIRS. Thus I don't thinks those variables are the cause.
Is there a way I can trace opening the Konqueror settings menu?
Darrell
On 03/07/2012 01:43 PM, Darrell Anderson wrote:
Some keyboard shortcuts stop, but I can recover that by deleting the user's khotkeys config file and starting afresh. That problem might be related or not, or might just be cruft from its KDE3 days when I migrated profiles.
Darrell,
I have begun capturing snapshots of the ~/.trinity config information to compare with previously migrated installs to help with this process. I too like to migrate configs rather than spend an hour going through each kcontrol setting and then going through each application specific setup (kate, kwrite, konsole, konqueror, etc...) This set of configs contains all normal base app settings from my TDE GIT install from 3-4 days ago. There are also a number of default keyboard shorcuts we may want to look at making default that utilize the 'Win' key for walking through desktops', 'next desktop', 'previous desktop', etc....
These (and others like them) would also make a fantastic set of NEW startup tips to improve on that feature and keep it relevant. I don't know if this will help with what you are doing, but I have made it available here:
[809k] http://www.3111skyline.com/dl/dt/tde/cnf/trinity-initial.tar.bz2
I have begun capturing snapshots of the ~/.trinity config information to compare with previously migrated installs to help with this process. I too like to migrate configs rather than spend an hour going through each kcontrol setting and then going through each application specific setup (kate, kwrite, konsole, konqueror, etc...) This set of configs contains all normal base app settings from my TDE GIT install from 3-4 days ago. There are also a number of default keyboard shorcuts we may want to look at making default that utilize the 'Win' key for walking through desktops', 'next desktop', 'previous desktop', etc....
These (and others like them) would also make a fantastic set of NEW startup tips to improve on that feature and keep it relevant. I don't know if this will help with what you are doing, but I have made it available here:
[809k] http://www.3111skyline.com/dl/dt/tde/cnf/trinity-initial.tar.bz2
Thanks.
There is a proposed migration shell script. I haven't tested in several weeks, but has worked well for me in the past.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=709
I'd appreciate others testing and comments. :)
Darrell