| Summary: | 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 | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Dennis Schridde <heri+kde> |
| Component: | Task Manager and Icons-Only Task Manager widgets | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | akselmo, nate, qydwhotmail, sandro.jaeckel |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | NixOS | ||
| OS: | Linux | ||
| See Also: | https://github.com/NixOS/nixpkgs/issues/322023 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Dennis Schridde
2025-05-31 15:33:05 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. (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 |