I have a laptop with a physical button to open gnome-calculator this works fine with deb application but doesn’t work with snap app. I noticed the same behavior with the browser. The button browser normally opens the browser but now it does nothing. Only if the browser is already open it takes you to home page
You need to find where those key shortcuts are defined and modify path for app which they execute.
Looking atthe code in gnome-settings-daemon, we have:
case CALCULATOR_KEY: do_execute_desktop_or_desktop (manager, "org.gnome.Calculator.desktop", "gnome-calculator.desktop", timestamp); break;
So it is looking for two particular desktop file IDs. However, due to the way snapd installs desktop files, it would instead have the ID
gnome-calculator_gnome-calculator.desktop, so isn’t found.
As for the web browser case, I don’t see a reason why it shouldn’t work for a snapped browser: it simply launches the default handler for the “http” scheme, so all you should need to do is to configure it in the default applications control panel.
I can observe the same behavior in gnome-calculator and gnome-system-monitor.
I tried different key combinations.
Vlc, Chromium and other snaps work.
Are there any plans to solve this?
In the meanwhile, this workaround worked for me:
$ sudo ln -s /var/lib/snapd/desktop/applications/gnome-calculator_gnome-calculator.desktop /var/lib/snapd/desktop/applications/gnome-calculator.desktop
Yes. I do want to fix the underlying problem (allowing snaps to specify their exact desktop file ID when it forms part of an API):
I’m not sure when I’ll have it fully sorted out though. The primary use case I’m interested in is APIs that are built on top of D-Bus activatable desktop entries, such as the GNOME 3 notification system. In this case, the name of the desktop file must match the D-Bus name the application acquires.
It has been on the back burner for a bit though, since we need to allow snaps to provide D-Bus activatable services first.
OK, thanks for the update! Hope it can be solved soon!