506032 2025-06-23 09:42:17 +0000 Cannot rename desktop links (shortcuts) 2025-07-31 17:19:50 +0000 1 1 4 Plasma plasmashell Desktop icons & Folder View widget 6.4.0 Arch Linux Linux RESOLVED FIXED NOR minor 1.0 446031 1 saulelis plasma-bugs-null akselmo hein kdedev nate https://invent.kde.org/plasma/plasma-workspace/-/commit/8df7d9aeffb82fe128113855c66605ef6a8457dc 6.4.4 0 oldest_to_newest 2435290 0 saulelis 2025-06-23 09:42:17 +0000 SUMMARY I am unable to rename the displayed name for .desktop files. Right clicking on them and selecting rename on the desktop or dolphin renames the .desktop file itself and not the displayed name. Trying to rename through the properties window's application tab's name field throws an error "Could not save properties due to insufficient write access to: 'home/name/Desktop/shortcut.desktop'". It does however work, if you use a text editor (such as Kate or Nano) to edit the "name" field. STEPS TO REPRODUCE 1. Try to rename a .desktop file either through the desktop itself, with dolphin or the file's properties window. OBSERVED RESULT The displayed name on the desktop stays the same. If edited through the desktop or dolphin the .desktop file name itself is changed. Trying to rename through the properties window throws an error. EXPECTED RESULT The displayed name is changed, keeping the original name of the .desktop file intact. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.15.3 KDE Plasma Version: 6.4.0 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION Checking the permissions for the .desktop files, each file's owner is root and not my user account, perhaps that has something to do with it? Though trying to change the owner with chown did not fix the problem. 2435876 1 nate 2025-06-24 17:57:08 +0000 Can you be specific about how you created the shortcuts that are on the desktop? 2435878 2 nate 2025-06-24 17:57:46 +0000 Was it by dragging apps installed from Flathub (user install, not system install) from Kickoff/kicker/etc to the desktop and then choosing "Link"? 2435879 3 saulelis 2025-06-24 18:01:48 +0000 I think one of them was from flathub (currently can't check), but most of the apps were installed using pacman (arch system). The shortcuts were created by right clicking the apps and selecting "Add to desktop" in the start menu (kickoff). 2435880 4 saulelis 2025-06-24 18:02:55 +0000 Will add, 2 of them were installed from the AUR. Seems like their origin is not related 2436435 5 kdedev 2025-06-26 00:50:58 +0000 I tested this on git-master and cannot reproduce Testing steps: 1. Right click an app from the app menu and choose Add to Desktop (tested with native Kate and Obsidian flatpak) 2. Right click the shortcut, choose rename The shortcut on the desktop has the new name The properties show the new name in the name field, and the .destop filename remains as it had been (e.g. /home/tracey/.local/share/applications/org.kde.kate.desktop) On KDE Neon User, and Neon Testing: The properties window shows the new name in the text field, and the correct name for the .desktop file but the shortcut on the desktop does not update, due to a permissions issue. That's a packaging issue on Neon, but it verifies the .desktop file does not change name. 2436528 6 saulelis 2025-06-26 09:28:30 +0000 I can try downloading plasma-deskqtop-git from the AUR (I believe that's the right package) then to see if the bug persists. Question: is mixing KDE enviroment packages a bad idea - I would esentially be only replacing the desktop while keeping all other plasma apps from the main (extra) repositories. 2436686 7 kdedev 2025-06-26 17:25:03 +0000 (In reply to zaliojicitrina from comment #6) > I can try downloading plasma-deskqtop-git from the AUR (I believe that's the > right package) then to see if the bug persists. Question: is mixing KDE > enviroment packages a bad idea - I would esentially be only replacing the > desktop while keeping all other plasma apps from the main (extra) > repositories. I would advise against mising environment packages. This can lead to an inconsistent system state, and would make things harder to test. I was testing on git-master to provide data, it isn't a workaround. Hopefully others will be able to reproduce this. 2437704 8 akselmo 2025-07-01 11:57:07 +0000 I can repro this: - If linked target is in user writable folder, the symlink can be renamed - If linked target is in flatpak or some other non-user writable folder, it can't be renamed One should be able to rename symlinks, since it shouldnt rename the target. Will investigate why it fails. Operating System: Fedora Linux 42 KDE Plasma Version: 6.4.80 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel Version: 6.15.4-200.fc42.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600 2437709 9 akselmo 2025-07-01 12:05:19 +0000 I think i get why: When renaming the symlink, it does actually rename it. However it cant rename the "friendly name" that is usesdon the desktop for name display, since that is under root ownership. What we could do instead is just show the symlink name if its symlink, but when creating new symlink for desktop file, use tve friendly name as its initial name. 2437736 10 bug-janitor 2025-07-01 13:39:20 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5648 2444208 11 akselmo 2025-07-31 10:21:33 +0000 Git commit 8b2f22c28d24b3a70765b71d83f3cde77320ab7d by Akseli Lahtinen. Committed on 31/07/2025 at 10:21. Pushed by akselmo into branch 'master'. DesktopProtocol: If symlink target desktop file is unwritable, create new one to ApplicationsLocation If user creates a symlink from applications launcher to desktop, and that symlink points to a flatpak related desktop file, it is unwritable. Therefore renaming it wont work, since rename process wants to rename the "friendly name" of the desktop file. In these cases, we copy the symlink target desktop file data, create new one to the `QStandardPaths::ApplicationsLocation`, delete the old symlink and replace it with new one which points to the one we just created. Since this is writable, it will rename correctly. M +14 -1 kioworkers/desktop/kio_desktop.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/8b2f22c28d24b3a70765b71d83f3cde77320ab7d 2444215 12 akselmo 2025-07-31 10:46:11 +0000 Git commit 8df7d9aeffb82fe128113855c66605ef6a8457dc by Akseli Lahtinen. Committed on 31/07/2025 at 10:21. Pushed by akselmo into branch 'Plasma/6.4'. DesktopProtocol: If symlink target desktop file is unwritable, create new one to ApplicationsLocation If user creates a symlink from applications launcher to desktop, and that symlink points to a flatpak related desktop file, it is unwritable. Therefore renaming it wont work, since rename process wants to rename the "friendly name" of the desktop file. In these cases, we copy the symlink target desktop file data, create new one to the `QStandardPaths::ApplicationsLocation`, delete the old symlink and replace it with new one which points to the one we just created. Since this is writable, it will rename correctly. (cherry picked from commit 8b2f22c28d24b3a70765b71d83f3cde77320ab7d) 955ad41c DesktopProtocol: If symlink target desktop file is unwritable, create new one... a4f1fcbc If newPath exists, only link it Co-authored-by: Akseli Lahtinen <akselmo@akselmo.dev> M +14 -1 kioworkers/desktop/kio_desktop.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/8df7d9aeffb82fe128113855c66605ef6a8457dc