The startkde script sets the XDG_DATA_DIRS variable to XDG_DATA_DIRS="`kde4-config --prefix`/share:/usr/share:/usr/local/share" if the variable is not set. The default if the variable is not set is to put "/usr/local/share:/usr/share". The startkde script should honour the preference of /usr/local over /usr so that files provided by the system package managment can be locally overriden without directly modifying them. If the setting of XDG_DATA_DIRS in startkde is really necessary I suggest to set it to "/usr/local/share:`kde4-config --prefix`/share:/usr/share". Reproducible: Always Steps to Reproduce: 1. copy a .desktop file from /usr/share/applications to /usr/local/share/applications 2. modify the applications name in /usr/local/share/applications (or any other property in the file) 3. Actual Results: The original name is shown instead of the modified one. Expected Results: The modified name should be shown in the menu.
Created attachment 78072 [details] Patch to update startkde in accordance with XDG and KDEDIRS specifications I agree with the original report. The XDG_DATA_DIRS specification says the same thing: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables In startkde the XDG_DATA_DIRS variable should be explicitly set only when KDE is installed in a non standard location, such as /opt. When KDE is installed in /usr then startkde should not be explicitly setting XDG_DATA_DIRS. I discovered the same basic problem as the OP when I modified my $KDEDIRS variable with an additional directory. Most of the files in that additional directory were not being recognized. Everything work as expected when I commented out the current XDG_DATA_DIRS snippet in startkde. The current startkde snippet works for most use cases only because many people never expand the $KDEDIRS variable and many distros are designed with XDG_DATA_DIRS already set. In the former case there is no damage and in the latter case the snippet never executes. I am attaching a patch for startkde.cmake in the kde-workspaces sources. The patch contains verbose comments about when to set XDG_DATA_DIRS so future developers are careful about changes.
Thanks for the patch. Could you create a review request at https://git.reviewboard.kde.org/ for it? I suggest to use kdelibs as reviewer group. For more information, see - http://techbase.kde.org/Contribute/Send_Patches - http://techbase.kde.org/Development/Review_Board
I tried creating a review request but I received an error message of "The selected file does not appear to be a diff."
(In reply to comment #3) > I tried creating a review request but I received an error message of "The > selected file does not appear to be a diff." How did you create that diff? As explained in http://techbase.kde.org/Development/Review_Board sending a request is best done with the "post-review" helper tool.
Standard method: diff -urN If you want to use the patch then create the review request. :)
Any progress with the review request?
https://git.reviewboard.kde.org/r/109675/ Looks related, but that "fix" has it's own set of problems.
I just found out that startplasma still does this: https://github.com/KDE/plasma-workspace/blob/master/startkde/startplasma.cpp#L193 It's so strange, since having the KDE_INSTALL_FULL_DATAROOTDIR first in XDG_DATA_DIRS apparently matters, but not enough to prepend it to an existing value. The swapped /usr/local/share and /usr/share just seems like a mistake to be honest.
Would you like to submit a diff to https://phabricator.kde.org/differential/diff/create/ to change it? Comment 7 mentions some problems with previous attempts, but these issues might no longer be applicable.
Sure, I'll give it a go.
Git commit 3c1a34a26dbdf7c123782746881d914cd47b27b6 by David Edmundson. Committed on 09/01/2020 at 16:30. Pushed by davidedmundson into branch 'master'. [startkde] Drop hack to manually set XDG_DATA_DIRS to the install root Summary: For normal distros it doesn't make sense, KDE_INSTALL_FULL_DATAROOTDIR will be /usr/. For devs using a prefix startplasma-dev.sh already does this for us only for the dev setup. For any other user, it should be their responsibility to adjust it. It's currently broken anyway, if a user simply installs flatpak that sets this env earlier in the boot, so this will do nothing. It implies no-oe relies on thisl It's a relic from 2007 (bd38d59e11548f160efd0918ca5461536ac72349) that doesn't make sense now. Test Plan: Compiles Reviewers: #plasma Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D26537 M +0 -8 startkde/startplasma.cpp https://commits.kde.org/plasma-workspace/3c1a34a26dbdf7c123782746881d914cd47b27b6