Hello, Below appears to affect all wayland compositors / environments (and X), respectively any panel / dock that has the ability to pin an application for quick launching when all it's surfaces are closed.
wayland api provides the appId / title (IIRC this is the xdg-shell protocol) X api provides the appId / title / icon custom wayland wlroots protocol wlr-foreign-toplevel-management provides the same The implementation of all desktops environments face the following problem, they need to match the appId to a desktop file to create a launcher, which is done by looking up in all the directories $XDG_DATA_DIRS until a desktop file matching the appId is found. This is completely broken by design, especially in the times of flatpak and snap. As an example take $application, it can be installed 1) from system package - desktop file goes into /usr/share/applications/ 2) from local build - desktop file goes into /usr/local/share/applications/ 3) from flatpak(system wide) - desktop file goes into /var/lib/flatpak/share/applications/ 4) from flatpak(user wide) - desktop file goes into $HOME/.local/share/applications/ 5) from flatpak(custom loc) - desktop file goes into $custom 6) from snap - desktop file goes into snap directory All of the above are exposed as $XDG_DATA_DIRS whatever application you pin depends on the priority the lookup is done, very often it will not pin the application it should! How can wayland help solve this problem? I imagine it could be possible additionally to appId and title to expose maybe the path to the actual binary? I'd be happy to hear some ideas to resolve this for all Linux desktop environments. Br, Damian _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
