Resolving bug report 892 includes important patches to reduce potential conflict with KDE4 and to make our own *.desktop files XDG compliant (recently Trinity/TDE was added to the list of registered environments: http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
The gritty work of creating patches to update all *.desktop files for each module is complete. Yet there is hard-coding somewhere deep in the tdelibs/tdebase sources that affixes the location of $PREFIX/share/applications/kde. I want to change that location to $PREFIX/share/applications/tde.
During testing, to change the location to $PREFIX/share/applications/tde, I modify the sources on-the-fly of every module by running the following snippet in my master build script:
echo "Fixing applications path in $APP_SOURCES_DIR." if [ -d $APP_SOURCES_DIR/cmake ];then find $APP_SOURCES_DIR/cmake -name TDESetupPaths.cmake -exec sed -i 's|${SHARE_INSTALL_PREFIX}/applications/kde|${SHARE_INSTALL_PREFIX}/applications/tde|g' {} ; fi if [ -d $APP_SOURCES_DIR/admin ]; then find $APP_SOURCES_DIR/admin -type f -exec sed -i 's|{datadir}/applications/kde|{datadir}/applications/tde|g' {} ; fi find $APP_SOURCES_DIR -type f -exec sed -i 's|share/applications/kde/|share/applications/tde/|g' {} ; echo
After I resolve the mysterious hard-coding I'll patch each module with this on-the-fly snippet.
tdelibs/tdecore/kstandarddirs.cpp has this snippet:
if (!strcmp(type, "xdgdata-apps")) return "applications/";
Notice there is no "kde" affixed to the path.
Therefore the "kde" subdirectory is being added somewhere else.
The on-the-fly changes work great and all desktop files get installed to $PREFIX/share/applications/tde. Nonetheless, there is breakage. The hard-coding is real because various components stop working in Trinity. For example, opening the Konqueror Settings dialog reveals that most of the configuration options in the icon list are missing. I can temporarily create a sym link from $PREFIX/share/applications/tde to $PREFIX/share/applications/kde and then everything works again --- evidence of hard-coding.
I've looked and looked and I can't find anything. I would be grateful anybody would help me find this mysterious hard-coding.
Darrell
Resolving bug report 892 includes important patches to reduce potential conflict with KDE4 and to make our own *.desktop files XDG compliant (recently Trinity/TDE was added to the list of registered environments: http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
<snip>
I am fairly certain that what you are looking for is in the file cmake/modules/TDESetupPaths.cmake, specifically the line which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses XDG_APPS_INSTALL_DIR as defined during the build process.
Tim
Resolving bug report 892 includes important patches to reduce potential conflict with KDE4 and to make our own *.desktop files XDG compliant (recently Trinity/TDE was added to the list of registered environments: http://standards.freedesktop.org/menu-spec/latest/apb.html).
Resolving this bug report is important to release R14.
<snip>
I am fairly certain that what you are looking for is in the file cmake/modules/TDESetupPaths.cmake, specifically the line which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses XDG_APPS_INSTALL_DIR as defined during the build process.
Tim
There is a second hardcode for the Autotools build system in admin/acinclude.m4.in, line 535. It looks like this: xdg_appsdir='${datadir}/applications/kde'
Tim
I am fairly certain that what you are looking for is in the file cmake/modules/TDESetupPaths.cmake, specifically the line which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses XDG_APPS_INSTALL_DIR as defined during the build process.
There is a second hardcode for the Autotools build system in admin/acinclude.m4.in, line 535. It looks like this: xdg_appsdir='${datadir}/applications/kde'
Yes, I have both of those locations covered in my master build script snippet. I just generated individual patches for each module. The tdelibs patch looks like this:
diff -urN tdelibs/admin/acinclude.m4.in tdelibs.new/admin/acinclude.m4.in --- tdelibs/admin/acinclude.m4.in 2012-05-10 15:54:53.000000000 -0500 +++ tdelibs.new/admin/acinclude.m4.in 2012-05-29 13:12:09.413139614 -0500 @@ -532,7 +532,7 @@ kde_widgetdir='${libdir}/trinity/plugins/designer' fi if test -z "$xdg_appsdir"; then - xdg_appsdir='${datadir}/applications/kde' + xdg_appsdir='${datadir}/applications/tde' fi if test -z "$xdg_menudir"; then xdg_menudir='${sysconfdir}/xdg/menus' diff -urN tdelibs/cmake/modules/TDESetupPaths.cmake tdelibs.new/cmake/modules/TDESetupPaths.cmake --- tdelibs/cmake/modules/TDESetupPaths.cmake 2012-05-10 15:54:52.000000000 -0500 +++ tdelibs.new/cmake/modules/TDESetupPaths.cmake 2012-05-29 13:12:09.840143049 -0500 @@ -61,7 +61,7 @@ _tde_internal_setup_path( INFO_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/info" "The info install dir (default ${SHARE_INSTALL_PREFIX}/info)" )
_tde_internal_setup_path( XDG_MENU_INSTALL_DIR "${SYSCONF_INSTALL_DIR}/xdg/menus" "The XDG menus dir" ) - _tde_internal_setup_path( XDG_APPS_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/applications/kde" "The XDG apps dir" ) + _tde_internal_setup_path( XDG_APPS_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/applications/tde" "The XDG apps dir" ) _tde_internal_setup_path( XDG_DIRECTORY_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/desktop-directories" "The XDG directory" ) _tde_internal_setup_path( XDG_MIME_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/mime/packages" "The install dir for the xdg mimetypes" )
Darrell
I am fairly certain that what you are looking for is in the file cmake/modules/TDESetupPaths.cmake, specifically the line which sets XDG_APPS_INSTALL_DIR
tde-config is generate from tdecore/tde-config.cpp.cmake, which uses XDG_APPS_INSTALL_DIR as defined during the build process.
There is a second hardcode for the Autotools build system in admin/acinclude.m4.in, line 535. It looks like this: xdg_appsdir='${datadir}/applications/kde'
Yes, I have both of those locations covered in my master build script snippet. I just generated individual patches for each module. The tdelibs patch looks like this:
diff -urN tdelibs/admin/acinclude.m4.in tdelibs.new/admin/acinclude.m4.in --- tdelibs/admin/acinclude.m4.in 2012-05-10 15:54:53.000000000 -0500 +++ tdelibs.new/admin/acinclude.m4.in 2012-05-29 13:12:09.413139614 -0500 @@ -532,7 +532,7 @@ kde_widgetdir='${libdir}/trinity/plugins/designer' fi if test -z "$xdg_appsdir"; then
- xdg_appsdir='${datadir}/applications/kde'
- xdg_appsdir='${datadir}/applications/tde' fi if test -z "$xdg_menudir"; then xdg_menudir='${sysconfdir}/xdg/menus'
diff -urN tdelibs/cmake/modules/TDESetupPaths.cmake tdelibs.new/cmake/modules/TDESetupPaths.cmake --- tdelibs/cmake/modules/TDESetupPaths.cmake 2012-05-10 15:54:52.000000000 -0500 +++ tdelibs.new/cmake/modules/TDESetupPaths.cmake 2012-05-29 13:12:09.840143049 -0500 @@ -61,7 +61,7 @@ _tde_internal_setup_path( INFO_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/info" "The info install dir (default ${SHARE_INSTALL_PREFIX}/info)" )
_tde_internal_setup_path( XDG_MENU_INSTALL_DIR "${SYSCONF_INSTALL_DIR}/xdg/menus" "The XDG menus dir" )
- _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/kde" "The XDG apps dir" )
- _tde_internal_setup_path( XDG_APPS_INSTALL_DIR
"${SHARE_INSTALL_PREFIX}/applications/tde" "The XDG apps dir" ) _tde_internal_setup_path( XDG_DIRECTORY_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/desktop-directories" "The XDG directory" ) _tde_internal_setup_path( XDG_MIME_INSTALL_DIR "${SHARE_INSTALL_PREFIX}/mime/packages" "The install dir for the xdg mimetypes" )
Darrell
Are you building with Autotools or CMake?
It might be a good idea to search in the /<TDE prefix>/bin and /<TDE prefix>/lib directories for the text string "applications/kde" to see which binary or library contains the hardcoded string. This will narrow the search down considerably.
Tim
Are you building with Autotools or CMake?
Both, depending on the module.
It might be a good idea to search in the /<TDE prefix>/bin and /<TDE prefix>/lib directories for the text string "applications/kde" to see which binary or library contains the hardcoded string. This will narrow the search down considerably.
Yes, my master build script (and the script I wrote to create the individual patches) searches the entire module for that string:
find $MODULE.new -type f -exec sed -i 's|share/applications/kde/|share/applications/tde/|g' {} ;
Darrell
Are you building with Autotools or CMake?
Both, depending on the module.
tdecore?
It might be a good idea to search in the /<TDE prefix>/bin and /<TDE prefix>/lib directories for the text string "applications/kde" to see which binary or library contains the hardcoded string. This will narrow the search down considerably.
Yes, my master build script (and the script I wrote to create the individual patches) searches the entire module for that string:
find $MODULE.new -type f -exec sed -i 's|share/applications/kde/|share/applications/tde/|g' {} ;
Darrell
Actually, I meant for debugging purposes to perform a text search inside the binary and library files themselves, not the source files.
Tim
Are you building with Autotools or CMake?
Both, depending on the module.
tdecore?
I meant that I use either automake or cmake, depending upon the moudle. In the case of tdelibs (tdecore), I use cmake.
Actually, I meant for debugging purposes to perform a text search inside the binary and library files themselves, not the source files.
I did that too, a long time ago. :-)
Nonetheless, I just now ran 'grep -a' against my current installation, which is built with $PREFIX/share/applications/kde. tde-config is the only executable with a reference to applications/kde and libkio.so is the only library file, but that library file reference is to applications/kde4. Changing to share/applications/tde would produce equivalent results.
I have tested with a new profile, to ensure the hard-coding is not there. Same results with Konqueror not loading the other Settings options.
In other words, I have beaten myself up pretty good trying to solve this mystery. I'll be quite tickled if somebody eventually shows me something obvious that I overlooked. I just want the mystery solved and don't care whether my eyesight or intelligence become suspect. :-)
At the moment I don't recall other breakages other than the Konqueror example, but I seem to recall other things. Possibly only Konqueror is broken and nothing else. Possibly the clue is in the Konqueror code only.
I'm going to try another run today with the new path of $PREFIX/share/applications/tde.
Darrell
Are you building with Autotools or CMake?
Both, depending on the module.
tdecore?
I meant that I use either automake or cmake, depending upon the moudle. In the case of tdelibs (tdecore), I use cmake.
Actually, I meant for debugging purposes to perform a text search inside the binary and library files themselves, not the source files.
I did that too, a long time ago. :-)
Nonetheless, I just now ran 'grep -a' against my current installation, which is built with $PREFIX/share/applications/kde. tde-config is the only executable with a reference to applications/kde
<snip>
Good to know. Please look in the generated tdecore/tde-config.cpp file and see if a reference to applications/kde is in there.
Tim
Good to know. Please look in the generated tdecore/tde-config.cpp file and see if a reference to applications/kde is in there.
Here is what I see that could be suspect:
... if (args->isSet("libsuffix")) { TQString tmp(KDELIBSUFF); tmp.remove('"'); printResult(expandvars(tmp.local8Bit())); return 0; } ... type = args->getOption("install"); if (!type.isEmpty()) { const char *installprefixes[] = { ... "data", "@kde_datadir@", ... "xdgdata-apps", "@xdg_appsdir@", "xdgdata-dirs", "@xdg_directorydir@", ...
I think I see where you are going with this: that apps call tde-config internally to determine where to find files. Possibly then the hard-coding is with tde-config, or, tde-config is not being built correctly to detect the changes I make in the respective automake/cmake files. Is there a way I can check the build logs to confirm how tde-config is built?
Darrell
Good to know. Please look in the generated tdecore/tde-config.cpp file and see if a reference to applications/kde is in there.
Here is what I see that could be suspect:
... if (args->isSet("libsuffix")) { TQString tmp(KDELIBSUFF); tmp.remove('"'); printResult(expandvars(tmp.local8Bit())); return 0; } ... type = args->getOption("install"); if (!type.isEmpty()) { const char *installprefixes[] = { ... "data", "@kde_datadir@", ... "xdgdata-apps", "@xdg_appsdir@", "xdgdata-dirs", "@xdg_directorydir@", ...
I think I see where you are going with this: that apps call tde-config internally to determine where to find files. Possibly then the hard-coding is with tde-config, or, tde-config is not being built correctly to detect the changes I make in the respective automake/cmake files. Is there a way I can check the build logs to confirm how tde-config is built?
Darrell
Unfortunately the build logs won't help you, but if you have access to your build directory look for the tdecore/tde-config.cpp file (note: NOT the tde-config.cpp.in or tde-config.cpp.cmake files) and see what follows "xdgdata*" in the source code.
Tim
Unfortunately the build logs won't help you, but if you have access to your build directory look for the tdecore/tde-config.cpp file (note: NOT the tde-config.cpp.in or tde-config.cpp.cmake files) and see what follows "xdgdata*" in the source code.
grep xdgdata $TMP/tdelibs.build/tdecore/tde-config.cpp
"xdgdata-apps", I18N_NOOP("XDG Application menu (.desktop files)"), "xdgdata-dirs", I18N_NOOP("XDG Menu descriptions (.directory files)"), "xdgdata-apps", "/opt/trinity/share/applications/tde", "xdgdata-dirs", "/opt/trinity/share/desktop-directories",
I'm building new test packages now and will report again soon with the installation results and Konqueror behavior.
Darrell
Unfortunately the build logs won't help you, but if you have access to your build directory look for the tdecore/tde-config.cpp file (note: NOT the tde-config.cpp.in or tde-config.cpp.cmake files) and see what follows "xdgdata*" in the source code.
grep xdgdata $TMP/tdelibs.build/tdecore/tde-config.cpp
"xdgdata-apps", I18N_NOOP("XDG Application menu (.desktop files)"), "xdgdata-dirs", I18N_NOOP("XDG Menu descriptions (.directory files)"), "xdgdata-apps", "/opt/trinity/share/applications/tde", "xdgdata-dirs", "/opt/trinity/share/desktop-directories",
I'm building new test packages now and will report again soon with the installation results and Konqueror behavior.
Darrell
When the rebuild finishes go ahead and search the tde-config binary again for "applications/kde". If the string is still in there please Email the binary to me directly so I can examine it more closely.
Thanks!
Tim
When the rebuild finishes go ahead and search the tde-config binary again for "applications/kde". If the string is still in there please Email the binary to me directly so I can examine it more closely.
No such string.
I just built a new package set (core packages only) to test $PREFIX/share/applications/tde. Same results. :-(
* All desktop files installed to /opt/trinity/share/applications/tde.
* grep -rna "applications/kde" /opt/trinity/lib produces no results
* grep -rna "applications/kde" /opt/trinity/bin produces no results
* grep -rna "applications/tde" /opt/trinity/lib produces no results
* grep -rna "applications/tde" /opt/trinity/bin produces one result: tde-config
* tde-config --install xdgdata-apps produces: /opt/trinity/share/applications/tde
* Opening Konqueror and selecting Settings/Configure Konqueror shows only four items in the left-side icon list: 1) Behavior, 2) Appearance, 3) Previews * Meta-Data, 4) Performance. All other configuration items are missing from the icon list.
* A new profile results in the same Konqueror behavior with only four items showing in the icon list.
* Creating a sym link (ln -s /opt/trinity/share/applications/tde /opt/trinity/share/applications/kde) and restarting the session results in all configuration items in the Konqueror icon list to appear.
* Session saving is disabled throughout this testing (start with new session).
* ksycoca cache was deleted before starting each desktop session.
Darrell
When the rebuild finishes go ahead and search the tde-config binary again for "applications/kde". If the string is still in there please Email the binary to me directly so I can examine it more closely.
No such string.
I just built a new package set (core packages only) to test $PREFIX/share/applications/tde. Same results. :-(
All desktop files installed to /opt/trinity/share/applications/tde.
grep -rna "applications/kde" /opt/trinity/lib produces no results
grep -rna "applications/kde" /opt/trinity/bin produces no results
grep -rna "applications/tde" /opt/trinity/lib produces no results
grep -rna "applications/tde" /opt/trinity/bin produces one result:
tde-config
- tde-config --install xdgdata-apps produces:
/opt/trinity/share/applications/tde
- Opening Konqueror and selecting Settings/Configure Konqueror shows only
four items in the left-side icon list: 1) Behavior, 2) Appearance, 3) Previews * Meta-Data, 4) Performance. All other configuration items are missing from the icon list.
- A new profile results in the same Konqueror behavior with only four
items showing in the icon list.
- Creating a sym link (ln -s /opt/trinity/share/applications/tde
/opt/trinity/share/applications/kde) and restarting the session results in all configuration items in the Konqueror icon list to appear.
- Session saving is disabled throughout this testing (start with new
session).
- ksycoca cache was deleted before starting each desktop session.
Darrell
I'm starting to recognize this pattern....try grepping for /kde in your XDG directories (that means your system XDG directory as well as your profile and the XDG directories under the TDE prefix). I suspect you will run across at least one .desktop file that contains the string.
Tim
I'm starting to recognize this pattern....try grepping for /kde in your XDG directories (that means your system XDG directory as well as your profile and the XDG directories under the TDE prefix). I suspect you will run across at least one .desktop file that contains the string.
Nothing there:
grep -rna "/kde" $TDEHOME
grep -rna "/kde" /opt/trinity | grep -v doc
Using a new profile, I disabled konqueror preloading. I started konqueror with strace using konsole.
Next I created a sym link (ln -s /opt/trinity/share/applications/tde /opt/trinity/share/applications/kde) and restarted the session. I again deleted the ksycoca cache and created another strace.
Other than the typical memory address differences, the two straces are identical. I had hoped to catch some kind of reference to "applications/kde" but there is none.
Interestingly, when I create the sym link I notice all TDE menu items repeat.
Because only core packages are installed, I can't test a variety of apps. Of those that are installed, I started kate, kwrite, kjobviewer, kcontrol, konsole. No noticeable problems.
Curiously, the same configuration items that are missing in the konqueror configuration icon list all appear in kcontrol -> Internet & Network -> Web Browser. Therein is a likely clue.
I'm starting to think the bug is in konqueror or in one of my *.desktop patches.
The thing about the patch set is there is no problem when I install all desktop files to $PREFIX/share/applications/kde during the build process or create the same sym link. Thus far I seem to notice the breakage only with konqueror.
Searching for "/kde" in my tdelibs and tdebase patches produced nothing.
I'm building the remaining packages of the main suite in order to have more apps to test. Please let me know what usability tests might help further isolate the problem.
I don't know where in the konqueror sources the configuration icon list is populated, but I suspect that is a good place to begin snooping. If I knew how konqueror populated its configuration icon list, then perhaps I could narrow the search to konqueror or related snippets in the patch set. Because the same configuration options appear in kcontrol, I'll take a wild guess that somehow konqueror parses the related desktop files incorrectly or simply can't find them.
Darrell
I'm starting to recognize this pattern....try grepping for /kde in your XDG directories (that means your system XDG directory as well as your profile and the XDG directories under the TDE prefix). I suspect you will run across at least one .desktop file that contains the string.
Could this be the problem?
In tdebase/konqueror/konq_mainwindow:3878
m_configureModules << "kde-filebehavior.desktop" << "kde-fileappearance.desktop" << "kde-filepreviews.desktop" << "kde-filetypes.desktop" << "kde-khtml_behavior.desktop" << "kde-khtml_java_js.desktop" << "kde-khtml_filter.desktop" << "kde-khtml_fonts.desktop" << "kde-ebrowsing.desktop" << "kde-kcmhistory.desktop" << "kde-cookies.desktop" << "kde-cache.desktop" << "kde-proxy.desktop" << "kde-kcmcss.desktop" << "kde-crypto.desktop" << "kde-useragent.desktop" << "kde-khtml_plugins.desktop" << "kde-kcmkonqyperformance.desktop";
Perhaps change the "kde-" prefix to "tde-"?
I'm rebuilding now with a patch....
Darrell
Could this be the problem?
In tdebase/konqueror/konq_mainwindow:3878
m_configureModules << "kde-filebehavior.desktop" << "kde-fileappearance.desktop" << "kde-filepreviews.desktop" << "kde-filetypes.desktop" << "kde-khtml_behavior.desktop" << "kde-khtml_java_js.desktop" << "kde-khtml_filter.desktop" << "kde-khtml_fonts.desktop" << "kde-ebrowsing.desktop" << "kde-kcmhistory.desktop" << "kde-cookies.desktop" << "kde-cache.desktop" << "kde-proxy.desktop" << "kde-kcmcss.desktop" << "kde-crypto.desktop" << "kde-useragent.desktop" << "kde-khtml_plugins.desktop" << "kde-kcmkonqyperformance.desktop";
Perhaps change the "kde-" prefix to "tde-"?
I'm rebuilding now with a patch....
Yes, Virginia, that is the problem! Woo-hoo! :-)
Looking through the sources reveals this is a common usage form for desktop files. Seems then I need to amend my patches to change instances in the source code of kde-*.desktop to tde-*.desktop.
Does this sound same?
Second, a full search of the GIT sources revealed one exception to a "blind" search-and-replace of all such instances: x-kde-wallet.desktop. This is a mimetype. For the purposes of resolving bug report 892, I don't want to mess with renaming that desktop file, but in the bigger picture, do we want to or should be? I don't know how renaming will break existing profiles.
Darrell
Yes, Virginia, that is the problem! Woo-hoo! :-)
Looking through the sources reveals this is a common usage form for desktop files. Seems then I need to amend my patches to change instances in the source code of kde-*.desktop to tde-*.desktop.
Does this sound sa[n]e?
To answer my own question, no, not quite sane. Blindly replacing all instances in the source code of kde-*.desktop -> tde-*.desktop causes a different set of weirdness and breakage. In tdebase/konqueror/konq_mainwindow:3878 I need to leave four of the references as kde-*.desktop:
kde-filepreviews.desktop kde-filetypes.desktop kde-khtml_behavior.desktop kde-kcmkonqyperformance.desktop
Curiously, those four files are installed to $PREFIX/share/applnk/.hidden rather than $PREFIX/share/applications/tde, albeit without the 'kde-' prefix in the file name.
The following modules contain references in the sources of kde-*.desktop:
applications/tde-systemsettings applications/kerry applications/kiosktool applications/knutclient tde-i18n tdebase tdebindings tdelibs tdevelop
I seem to be over the hump with respect to finding the hidden hard-coding, but I don't know of a systematic way to test which kde-*.desktop references in the source code should be renamed. Thus far, a simple random usability test of the desktop reveals only those konqueror references needing to be renamed. I suppose a full package rebuild and installation might reveal more, but then again, might not.
Any ideas how to isolate which ones need renaming?
I'm curious why this weird behavior happens. Any ideas?
Darrell
-
Darrell Anderson -
Timothy Pearson