https://bugs.kde.org/show_bug.cgi?id=505066
cwo <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #10 from cwo <[email protected]> --- 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. -- You are receiving this mail because: You are watching all bug changes.
