Bug 505066 - Pinning app to Task Manager saves it to config file as an absolute path to its .desktop file if it's packaged in certain ways, which is fragile and can break in the future
Summary: Pinning app to Task Manager saves it to config file as an absolute path to it...
Status: CONFIRMED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager widgets (other bugs)
Version First Reported In: 6.3.5
Platform: NixOS Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-05-31 15:33 UTC by Dennis Schridde
Modified: 2025-08-14 15:19 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Schridde 2025-05-31 15:33:05 UTC
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
Comment 1 Nate Graham 2025-06-04 17:09:14 UTC
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.
Comment 2 Dennis Schridde 2025-06-06 12:27:55 UTC
(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?
Comment 3 Bug Janitor Service 2025-07-03 09:23:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kservice/-/merge_requests/205
Comment 4 Akseli Lahtinen 2025-07-25 12:02:16 UTC
This bug may have been resolved with https://invent.kde.org/frameworks/kservice/-/commit/09ec46a6d9c15e4ce4935df07a06cac918c7004e

If possible, can you test this out?
Comment 6 Bug Janitor Service 2025-08-10 03:46:20 UTC
๐Ÿ›๐Ÿงน โš ๏ธ 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!
Comment 7 Dennis Schridde 2025-08-10 07:57:02 UTC
I'll test KDE Frameworks 6.17 once it lands in NixOS unstable. Until then see Sandro's reply.
Comment 8 Dennis Schridde 2025-08-13 21:06:06 UTC
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