SUMMARY An issue that was annoying me for a while. The "Edit app entry" menu for flatpak apps can't edit entry for any flatpak app, giving no permission error, even if an app is installed for user and not for system, so the desktop file has user as owner STEPS TO REPRODUCE 1. Install an app from flatpak, lets take Ente Auth 2. Find it in application launcher widget 3. Right click on it and choose "Edit app entry" (probably not exactly how it's named, my system is not in English) 4. Try to edit it's name to something else 5. Try to apply OBSERVED RESULT Gives a permission error or suggests overwriting the file (?) EXPECTED RESULT Should just apply the changes SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.9.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION Sometimes "Edit Applications..." can apply changes to these entries succesfully, sometimes it doesn't show any errors and just doesn't apply changes as well.
> Sometimes "Edit Applications..." can apply changes to these entries succesfully, sometimes it doesn't show any errors and just doesn't apply changes as well. This refers to the one opened from right click menu of app launcher
I discovered that it isn't a flatpak only problem by trying to edit Discord launch parameters. Since the original .desktop file of Discord is in /opt, and applications folder have just a symlink to it, the Plasma editor couldn't edit it.
Works for me with git master and a Flatpak app, perhaps due to using KMenuEdit for this there rather than the properties dialog, or other system changes in master. Oliver, can you confirm?
Properties doalog is the issue. KMenuEdit only rarely can't save changes
Never mind It's very weird and inconsistent Here's list of apps I tried editing in KMenuEdit and Properties (Name - Package type - Result): Discord - Native (located in opt with symlinked .desktop file) - KMenuEdit and Properties fail to edit SysD Manager - Flatpak (system) - both can edit Warehouse - Flatpak (system) - both can edit Parsec - Flatpak (system) - both can't edit Bedrock Launcher - Flatpak (system) - both can't edit Ryujinx - Flatpak (sytem) - both can't edit Discover Overlay - Flatpak (user) - both can't edit Ente Auth - Flatpak (system) - both can't edit Properties menu gives an error, KMenuEdit doesn't say anything, but closing it and opening back reveals that changes weren't applied. Also, the error message of Properties menu makes panels unusable while it's open, which is weird. I have no other apps that store .desktop files in /opt and symlink it
For the native apps - that is likely a problem with how Arch is packaging Discord. I can't reproduce this with native apps (including Discord) on Solus (on Plasma or Budgie). Each distro determines where the .desktop files go. (It looks like Discord is the only app you've found with this issue). I recommend reporting the problem with Discord to them. Let's focus on the flatpak menu items in this report. I've narrowed down the problem that the Properties dialog of the menu entry is creating the broken symlink, other DEs / menu editors do not and are able to save changes # Background ## Where flatpaks store the .desktop file is up to each flatpak. This is true no matter if you install them through Discover or via command line. The default and usual place for the .desktop file is under /var/lib/flatpak/app/appname/... e.g. app/org.wezfurlong.wezterm/current/active/export/share/applications/org.wezfurlong.wezterm.desktop My testing showed that the error in Plasma when editing a flatpak menu item happens regardless of distro whenever the .desktop file trying to be saved is in a place the user can't write to or it has a bad symlink. ## The problem : the menu Property entry saves a symlink to the main .desktop file with a broken symlink instead of a new .desktop file under the user directory ## After testing on KDE Plasma and Budgie, installing a flatpak through command line, I observed: - On both Plasma and Budgie, flatpaks installed their .deskop file correctly to /var/lib/flatpak/app/appname/current/active/export/share/applications/org.appname.desktop. At this point, no .desktop file exists under ~/.local/share/applications/ - After attempting to edit a menu entry for a flatpak (for example Obsidian) - On Budgie, by editing the entry through MenuLibre - Changes can be saved and a .desktop file is created at ~/.local/share/applications/md.obsidian.desktop - On Plasma, by right clicking the menu entry - the error appears, changes are not saved, and a broken symlink is created at ~/.local/share/applications/md.obsidian.Obsidian.desktop which points to md.obsidian.Obsidian.desktop -> ../../../app/md.obsidian.Obsidian/current/active/export/share/applications/md.obsidian.Obsidian.desktop Testing details: My results were the same on Plasma 6.2.4 and git-master (Solus) as well as KDE Neon. I have a few flatpaks and quite a few native packages, but no .desktop files in /opt ### Native apps ### - Discord - ok ✅ ### flatpaks ### - WezTerm - same error as in the report. Could not save properties due to insufficient write access to: `/home/user/.local/share/applications/org.wezfurlong.wezterm.desktop` The .desktop file is a broken symlink file ~/.local/share/applications/org.wezfurlong.wezterm.desktop /home/user/.local/share/applications/org.wezfurlong.wezterm.desktop: broken symbolic link to ../../../app/org.wezfurlong.wezterm/current/active/export/share/applications/org.wezfurlong.wezterm.desktop - SysD Manager - same error as WezTerm, same cause (broken symlink) - VSCodium (com.vscodium.codium) - same error, same cause On KDE Neon, I get the same error for the Visual Studio flatpak. The broken link is the same. ~/.local/share/applications/com.visual...
I tested with KMenuEdit on master and things work as expected with that I'm able to edit flatpak menu entries and save them. No broken symlink is created under ~/.local/share/applications/. A copy of the default .desktop file is properly created
I can't reproduce it in KMenuEdit either. For Plasma 6.3, KMenuEdit has been made the only user-facing method of editing apps' desktop files from Kickoff, which means the bug has effectively been fixed.
Waiting for Plasma 6.3 I guess. Thanks.