SUMMARY Currently, when dragging an icon from the Application Launcher to the Icons Only Task Manager, the `launchers` property of `[Containments][N][Applets][M][Configuration][General]` in `~/.config/plasma-org.kde.plasma.desktop-appletsrc` will reference the absolute path name / absolute URL, e.g. `file:///nix/store/6j0kc3hvb4s5wrpz0aaxcmd3fdjgp56g-system-path/share/applications/signal.desktop`, instead of the location-independent form, e.g. `applications:signal.desktop`, that is used when selecting "Pin to Task Manager" for a running application's window. It would be nice if the location-independent form would always be used. I.e. if the behaviour of clicking "Pin to Task Manager" in the Task Manager's right-click menu for a running application's window would be applied also when dragging an icon to the Task Manager. The current behaviour causes problems when the absolute path changes, cf. https://github.com/NixOS/nixpkgs/issues/322023. STEPS TO REPRODUCE 1. Create a panel with Icons Only Task Manager 2. Drag an icon from Application Launcher to Icons Only Task Manager 3. Inspect `~/.config/plasma-org.kde.plasma.desktop-appletsrc` and find a `file://...` URL with absolute path 4. Start an application 5. Right-click on the Task Manager icon for the open window of that application and select "Pin to Task Manager" 6. Inspect `~/.config/plasma-org.kde.plasma.desktop-appletsrc` and find an `applications:xxx.desktop` URI OBSERVED RESULT A `file://...` URL with absolute path is used. EXPECTED RESULT A location-independent `applications:xxx.desktop` URI is used. SOFTWARE/OS VERSIONS Operating System: NixOS 25.11 KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.15.0 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 30,6 GiB of RAM Graphics Processor 1: AMD Radeon 680M Graphics Processor 2: AMD Radeon RX 6800S Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0
In testing, it looks like the newly-pinned app gets saved with an absolute path rather than just a desktop file name based on how it's packaged, not based on how it's pinned. For example, if I pin an app that came from Fedora packaging or was built-from source, it always gets saved as a desktop file name. But if I pin an app from Flathub, it always uses an absolute path. Need to look into the exact conditions that trigger this logic, and possibly move away from it.
(In reply to Nate Graham from comment #1) > In testing, it looks like the newly-pinned app gets saved with an absolute > path rather than just a desktop file name based on how it's packaged, not > based on how it's pinned. Thanks for looking into the matter. FYI: I only have Signal (the app I noticed the problem with) installed from NixOS. There is currently no Signal Flatpak is installed. Also, as far as I can tell, there is currently no file from a Flatpak present -- if I ever had the Signal Flatpak installed on that computer. Maybe we're seeing an intersection of multiple causes for this issue?
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kservice/-/merge_requests/205
This bug may have been resolved with https://invent.kde.org/frameworks/kservice/-/commit/09ec46a6d9c15e4ce4935df07a06cac918c7004e If possible, can you test this out?
This is the same patch as NixOS is carrying since a very long time https://github.com/NixOS/nixpkgs/blob/master/pkgs/kde/frameworks/kservice/qdiriterator-follow-symlinks.patch Not sure if deleton is part of this bug https://github.com/NixOS/nixpkgs/blob/master/pkgs/kde/frameworks/kservice/handle-sycoca-deletion.patch
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
I'll test KDE Frameworks 6.17 once it lands in NixOS unstable. Until then see Sandro's reply.
I updated to KDE Frameworks 6.17 (NixOS 25.11.20250812.005433b) and the issue persists as Sandro predicted. Operating System: NixOS 25.11 KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.17.0 Qt Version: 6.9.1 Kernel Version: 6.16.0 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 9 6900HS with Radeon Graphics Memory: 32 GiB of RAM (30,6 GiB usable) Graphics Processor 1: AMD Radeon RX 6800S Graphics Processor 2: AMD Radeon 680M Manufacturer: ASUSTeK COMPUTER INC. Product Name: ROG Zephyrus G14 GA402RK_GA402RK System Version: 1.0
Can confirm I see the same issue in Plasma 6.6.2
The problem here is that there's a bunch of symlinks involved with Flatpaks. Taking Audiotube as an example, there's - the canonical /var/lib/flatpak/exports/share/applications/org.kde.audiotube.desktop which links (relatively) to "../../../app/org.kde.audiotube/current/active/export/share/applications/org.kde.audiotube.desktop" (by canonical I mean that this is the one that's reachable from XDG_DATA_DIRS, and the most general, not as in "canonical file path" - in that sense it's the least canonical) - /var/lib/flatpak/exports/share/applications/../../../app/org.kde.audiotube/current/active/export/share/applications/org.kde.audiotube.desktop, i.e. /var/lib/flatpak/app/org.kde.audiotube/current/active/export/share/applications/ - Both /var/lib/flatpak/app/org.kde.audiotube/current/ and /var/lib/flatpak/app/org.kde.audiotube/current/active are themselves symlinks, so the final resolved filename (unless I missed yet another indirection) is /var/lib/flatpak/app/org.kde.audiotube/x86_64/stable/3c34f814205ec969062fe9db5ea49b6d2edec8cdf2b95d252e123ccfed69f498/export/share/applications/org.kde.audiotube.desktop KSycoca and KService(Factory) use the canonical name as entryPath and for findServiceByDesktopName. When using Kickoff's context menu entry "Pin to task manager), kickoff will try to pin using the (canonical) entryPath. Libtaskmanager, however does not use this, but instead loads the url into a KDesktopFile and takes its fileName(), then tries to look that up in KService. This probably makes sense in some situations (e.g. if we're trying to add a symlink on the desktop that's pointing to a /usr/share/applications .desktop file, we would want to look up the target, as that one is in the database), but breaks here. We could solve this by just trying to look up both the .desktop file name as provided by the caller, and the resolved .desktop file name as returned by KDesktopFile. However, for drag&drop we do yet another thing: here we can't use the canonical form, because that is a relative symlink (see above). So if we symlink that somewhere else (for example by dragging it onto the desktop), the link would be broken as it only makes sense in its original directory. There, we instead resolve it (partially; active and current are left unresolved - reasonably so, or a symlink to one of them might break on updates) and turn it into an absolute path. And again, we end up with something that's not in the database, and this time the task manager does not have the real one. Not quite sure how to best solve this.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6905
Git commit 85348a3efb51f129d767ba9f953f2bede1e45d24 by Christoph Wolk. Committed on 12/08/2026 at 05:33. Pushed by cwo into branch 'master'. libtaskmanager/launchertasksmodel: use better menuId lookup When pinning a launcher to the task bar from outside (kicker/kickoff or drag&drop), libtaskmanager tries to find the menuId so it can pin them as applications: urls, rather than the specific file system paths they have at that moment. The problem is that it only handles symlinks in one direction: if the new .desktop file is a symlink of an actual .desktop file that lives in an applications directory (which are what ksycoca indexes). But with Flatpak we instead have these files being symlinks (through several levels of indirection) to real .desktop files that live elsewhere. This means that attempts to pin one of these will generally fail, as they will use either the applications directory paths, or even a mixed one where some symlinks are resolved to their targets and others are not. To fix this, we add two more options. The first handles the case of using the "Pin to task manager" function in kicker/kickoff) just uses the url as passed in, which is already correct, rather than resolving it to find the actual .desktop file. The second is for drag&drop from elsewhere; we resolve the final canonical path, take its .desktop file name (which has to be the menuId if this is a desktop file from an applications directory), and look that up via KService. If both point to the same file, we have a match, and can use the menuId. If none of the approaches work, we're looking at a .desktop file that is not in ksycoca. FIXED-IN: 6.8.0 M +26 -6 libtaskmanager/launchertasksmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/85348a3efb51f129d767ba9f953f2bede1e45d24