SUMMARY If you want to make an edit to a .desktop file for an application installed system-wide, like via Flatpak, and attempt to do so via the right-click menu of an application in Kickoff, a symlink to the .desktop file will be created in `$XDG_DATA_HOME/applications` , and the file will be uneditable. STEPS TO REPRODUCE 1. Right click on a Flatpak application in Kickoff 2. Click "Edit Application..." 3. Attempt to make edits to the application OBSERVED RESULT All attempted edits fail, because the file made in `$XDG_DATA_HOME/applications` is a **symlink** to a file that is not user-writable. EXPECTED RESULT A **copy** of the file is made in `$XDG_DATA_HOME/applications`, and is thus editable. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon 5.24 KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION The case that made me notice this was attempting to edit Spotify's launcher after installing it via Discover; its default install method is system-wide. I wanted to add `--force-device-scale-factor 1.25` to the command line args but couldn't until I changed the symlink in `$XDG_DATA_HOME/applications` to an actual copy. Even if this is meant to somehow detect when the original .desktop files would be user-editable, like for the user Flatpak installation, I believe it is better to create a copy of the .desktop file so that changes are not lost on updates. I don't want to be forced to redo edits to get my desired scaling back every time Spotify updates.
Is this still reproducible with Frameworks 5.95? It's working for me, and I recall some changes that might have fixed it. Can you check? Thanks!
(In reply to Nate Graham from comment #1) > Is this still reproducible with Frameworks 5.95? It's working for me, and I > recall some changes that might have fixed it. Can you check? Thanks! I just tried it, and it still creates a symlink to the desktop file in a non-user-writeable system Flatpak installation. Even if there's some (currently failing) logic to check if a .desktop file's location is writeable, like for example if it points to the per-user Flatpak installation instead of a system one, it should still be copying the desktop file instead, because if it's symlinked, an update will overwrite the user's changes.
I think I've made a breakthrough here. This is *mostly* a Flatpak-specific issue, and here is why. I just tested out trying to edit an application I've installed in a custom system-wide Flatpak installation, located at `/xusr/flatpak`. I try to change its name, it fails, then I go look at the file it made. It is a symlink instead of a copy, but here's where it gets interesting. Flatpak wants you to put the `exports/share` directory in XDG_DATA_DIRS so that the DE can read the applications in `exports/share/applications`, and it does that automatically nowadays, but here is the rub: everything in that directory is already a symlink! I checked the points-to field of the resulting symlink that was made in `$XDG_DATA_HOME/applications`. It's not pointing to `/xusr/flatpak/exports/share/applications/com.github.unrud.VideoDownloader.desktop`. It's pointing at `/xusr/flatpak/app/com.github.unrud.VideoDownloader/current/active/export/share/applications/com.github.unrud.VideoDownloader.desktop`, which is the *target* of the first file. I think the reason I had not realized this was the case was because if you use `cp` to copy that file, it dereferences all the symlinks on the way to the actual file without you having to specify the `-L` argument. I am not sure why it does that. But Plasma really was already copying the file... it was just copying the symlink as-is. What it needs to do is dereference every symlink it finds on the way.
*** This bug has been marked as a duplicate of bug 450727 ***