The cause of this is:
1. You install a snap.
2. GNOME Software generates a notification, with a button that will contact the GNOME Software process and perform the action "app.launch" with the app ID. (gs-common.c:gs_app_notify_installed)
3. GNOME Software uses the ID as a desktop ID (i.e. the name of a .desktop file) to launch the application via the GAppInfo object (gs-application.c:launch_activated)
Where this fails is G-S is assuming that the application ID matches the desktop ID. This is best practise for modern XDG compliant apps, but is not enforced.
This assumption always fails in the general case for Snaps, and the ID used is a generated AppStream ID like io.snapcraft.moon-buggy-2kkitQurgOkL3foImG4wDwn9CIANuHlt.
The cause of this is: c:gs_app_ notify_ installed) .c:launch_ activated)
1. You install a snap.
2. GNOME Software generates a notification, with a button that will contact the GNOME Software process and perform the action "app.launch" with the app ID. (gs-common.
3. GNOME Software uses the ID as a desktop ID (i.e. the name of a .desktop file) to launch the application via the GAppInfo object (gs-application
Where this fails is G-S is assuming that the application ID matches the desktop ID. This is best practise for modern XDG compliant apps, but is not enforced.
This assumption always fails in the general case for Snaps, and the ID used is a generated AppStream ID like io.snapcraft. moon-buggy- 2kkitQurgOkL3fo ImG4wDwn9CIANuH lt.
The initial solution was to explicitly pass the desktop ID, but this seemed a bit of a hack an unlikely to be upstreamable. https:/ /gitlab. gnome.org/ robert. ancell/ gnome-software/ tree/notificati on-launch- desktop- id
The second solution was to continue to pass the ID, but instead to have plugins do the launching, that way the Snap plugin could work out the binary to run. https:/ /gitlab. gnome.org/ robert. ancell/ gnome-software/ tree/notificati on-launch- plugin
The latter solution turns out to be non-trivial to implement.