wlr-foreign-toplevels pid

[damianatorrpm]

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

from system package - desktop file goes into /usr/share/applications/
from local build - desktop file goes into
/usr/local/share/applications/
from flatpak(system wide) - desktop file goes into
/var/lib/flatpak/share/applications/
from flatpak(user wide) - desktop file goes into
$HOME/.local/share/applications/
from flatpak(custom loc) - desktop file goes into $custom
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!

A solution is to provide the PID and than being able to find the binary,
which was suggested by the mailing thread to wayland-devel

appId title / Iconic dock launchers

Consider adding the PID to wlr-foreign-toplevels

[emersion]

Duplicate of #77

Please refrain from opening duplicate issues.