Open peterzen opened 9 months ago
Can you please include the journalctl error messages here for people not running on a snap capable system?
@Jacalz does this relate to flatpack rules / fixes?
@Jacalz does this relate to flatpack rules / fixes?
I don't think so. To be fair, I have no idea about how Snap works and if they expose the XDG Desktop Portal API (it's not specific to Flatpak in any way; it even works outside of it on my system so it's possible they do). But then again, I don't think they have any systray API available through the portal API.
I honestly doubt that this is a bug in our code. The most likely culprit that I see is that your sandbox permissions isn't letting the DBus talk name through. You probably need to update your snap manifest (or whatever it's call there) to do something similar to what we do for notifications in flatpak_demo:
However, I do realise that I have never tried getting systray to work in Flatpak so I ought to test that sometime.
It would probably be a good idea to look at another Snap application that has a working systray and see how they have their permissions set up.
It would probably be a good idea to look at another Snap application that has a working systray and see how they have their permissions set up.
Is there something special about systray's approach vs other implementations (due to its cross platform nature perhaps)? I'll admit I don't know much about DBus and the way it's integrated into the GNOME desktop environment but from extensive testing it would appear that its DBus use is somewhat different than other apps'.
- See AppArmor DENIED messages in the log:
Can you please include the journalctl error messages here for people not running on a snap capable system?
The log messages above are gathered from journalctl.
I honestly doubt that this is a bug in our code. The most likely culprit that I see is that your sandbox permissions isn't letting the DBus talk name through.
I don't think it's a bug either - it's indeed the apparmor permissions put in place by snapd
that prevent it from talking to DBus on GNOME (there's no problem on KDE).
You probably need to update your snap manifest (or whatever it's call there) to do something similar to what we do for notifications in flatpak_demo:
The officially supported way in snap is via its interfaces (desktop-legacy and desktop), which essentially add apparmor
rules that enable specified DBus connectivity.
This is a similar problem someone had a while back, it's not related to this issue but it sheds a light on how he went about debugging it:
https://forum.snapcraft.io/t/trouble-to-get-electron-apps-systray-icon-working-as-a-snap/26623
(I did a flatpak also from the same app also, didn't have any issues.)
@Jacalz does this relate to flatpack rules / fixes?
I don't think so. To be fair, I have no idea about how Snap works and if they expose the XDG Desktop Portal API (it's not specific to Flatpak in any way; it even works outside of it on my system so it's possible they do). But then again, I don't think they have any systray API available through the portal API.
I honestly doubt that this is a bug in our code. The most likely culprit that I see is that your sandbox permissions isn't letting the DBus talk name through. You probably need to update your snap manifest (or whatever it's call there) to do something similar to what we do for notifications in flatpak_demo:
@jslarraz kindly tracked down this problem in the Snapcraft forum and provided a potential fix: https://forum.snapcraft.io/t/dbus-related-apparmor-denials/37422/1
Apparently the issue is related to the Dbus path Systray uses.
If that is the case then it appears that the snap configuration has decided to be less flexible than the specification. Perhaps someone with snap could test the modified path and check it works for us. I don't see any reason we can't change our published path to satisfy their requirements.
Checklist
Describe the bug
I have a Go application that uses
systray
to implement a tray menu, which works as expected on GNOME and KDE. When packaged up as a snap, however, the snap sandbox prevents the menu to function properly. I'm wondering if this is something others have noticed or potentially found a solution for?The problem occurs on GNOME, but does not on KDE, it can be reproduced by running the Fyne systray example.
How to reproduce
devmode
:example
--devmode
:example
DENIED
messages in the log:(further log information can be obtained using the
snappy-debug
tool.).snap
file to a KDE system, install it without--devmode
. Run the app, observe the systray menu being fully functional.Log messages
Example code
https://github.com/peterzen/systray-example-snap
Fyne version
fyne.io/systray v1.10.0
Go compiler version
1.21.3
Operating system and version
Ubuntu Linux 22.04, 20.04
Additional Information
From the logs it would appear that the Fyne systray lib tries to talk to the system/session dbus, but some of the AppArmor rules created by the sandbox do not allow it. (When the snap is installed with
--devmode
, the AppArmor rules do not apply, hence the app working correctly in that case.)Other Snap applications with systray integration work correctly on both KDE and GNOME, that indicates that the problem is related to the way Fyne systray uses the dbus. See https://snapcraft.io/signal-desktop as an example.