Currently snapd installs a renamed version of desktop files. For example gnome-logs installs gnome-logs_gnome-logs.desktop. GNOME Shell attempts to match the application name to a desktop file of the same name. Since the name doesn’t match, it results in a broken image and name in the applications appmenu as well as in the alt-tab switcher. See screenshot below.
I’m not sure if we should work on making GNOME query the snap for the desktop file or solve this some other way. Thoughts?
The problem we have and that the current convention solves is the one of namespacing.
What happens if two different snaps ship an application named “gnome-logs”? Also, is the name being looked for the one that the snap is called with, or the binary one? My guess is that it’s the binary one, which means neither the snap name nor the snap application name would fix the problem in the general case.
We’re not tightly bounded to any particular convention, as long as we can handle the general case correctly, and without conflicts.
I found a problem here.
Many gnome shell extensions look for applications based on desktop file names.
For example, in system-monitor extension there is a code that looks like this:
let _gsmApp = Shell.AppSystem.get_default().lookup_app('gnome-system-monitor.desktop');
_gsmApp.activate();
The problem is that if gnome-system-monitor is installed using Snap (as is now with Ubuntu 18.04) the name of the desktop file is ‘gnome-system-monitor_gnome-system-monitor.desktop’ so It’s not found and not launched.
I’m new to Snap but seem like there is a solution for binary resolution (/snap/bin files are links to /usr/bin/snap). How is binary namespace solved? Shouldn’t be applied to desktop files?