Hello. With an upcoming version of Varia (https://snapcraft.io/varia), I will need some extra permissions. This is the relevant part of snapcraft.yaml. I’m planning to release it very soon:
reasoning: I need read/write permission to $HOME/.config/autostart for the upcoming run on startup functionality. (added with commit 4f9087612c448e3e21dcc6ccb07aec0af4baee54)
Hello. I have worked further on the autostart function to use the relevant XDG Desktop portal instead of having direct access to .config/autostart. Therefore you can discard the personal-files (r/w to $HOME/.config/autostart) interface as it’s no longer needed and instead should be covered by the desktop interface.
com.canonical.dbusmenu was needed because it’s needed for the tray icon functionality, implemented using DBus, with a menu that allows the user to show or quit Varia through the tray icon.
Hi @giantpinkrobots - Is it possible to adjust the DBus name to represent the identity of the snapped application rather than canonical? Similarity to dbus-varia-tray (#askForInfo)
Are you sure that Varia needs to slot a dbus interface for com.canonical.dbusmenu rather than plug it?
If I’m right, slotting com.canonical.dbusmenu would allow Valia to act like a service, serving requests sent to com.canonical.dbusmenu by other consumer applications what feel wrong to me in this case.
My implementation exports to com.canonical.dbusmenu to have the tray icon menu. I couldn’t use libayatana-appindicator as its GPL-3 license is incompatible with Varia’s. I have so far exhausted all the other options that I could come up with.
If this is not allowed on Snap Store I can just disable tray functionality on the Snap version, however I would love to find a solution to this as I’ve already disabled the shutdown on completion feature for Snap due to permission issues and this would be the second one, making the Snap release a uniquely broken version compared to Flatpak. A lot of my users asked for tray functionality.
Would you be able to show the full slots and plugs definitions when you’ve applied desktop-legacy?
Getting the tray functionality to work via com.canonical.dbusmenu should work, it’s just that we’d expect you to not have to ask for approval. If you e.g., snap install joplin-desktop, on its settings screen, you’d be able to see you can turn on a tray icon and it works, that package doesn’t use any DBus slots, but the tray icon is provided by the desktop-legacy plug using that same DBus API.
I’d be keen on ensuring that you don’t happen to have a DBus slot (explicitly your dbusmenu slot, not dbus-varia-tray) defined for the tray icon alongside the desktop-legacy plug simultaenously, but generally it’s more we wouldn’t expect you to need to ask for approval rather than the functionality is itself privileged.
You can see the definitions that should be allowing it to work here: