btw, if you need a workaround, I know one: you can add a org.freedesktop.DBus.StartServiceByName call before calling any method on org.freedesktop.Notifications.
Thanks for the tip. We use org.freedesktop.Notifications indirectly (through Qt) and I would rather avoid reaching into DBus details just to work around. But, with your tip, I was able to get notifications after triggering the service, which allowed me to disentangle this from the other issue we’re having on MATE (missing icon).
If you’re talking about https://github.com/canonical/multipass/issues/2258, it’s due to the inability to scan processes. The thing is Ubuntu MATE replaces MATE’s proper SNI support with Unity’s AppIndicators. AppIndicators support only a part of SNI spec (e.g. no IconPixmap support that Qt uses, that’s why you see the stub instead of the icon). Qt has a workaround, it scans processes and tries to find indicator-application process. If it finds it, Qt assumes AppIndicators are in use and saves the pixmap to a temp directory with specifying it as IconName (what is supported by AppIndicators).
Thanks @ilya-fedin, very interesting and useful! I hadn’t pay much attention to the ptrace denial because I got it under GNOME as well. I guess not finding the process just happens to be the right outcome there.
I am producing a snap with system-observe now to see if that helps.
I haven’t inspected the ptrace, I ran into this long time ago and found this by looking at Qt code. As a result, I was forced to grow a custom SNI protocol implementation in the application I was encountered this instead of using QSystemTrayIcon (since probably no one would allow me to request auto-connect of system-observe just for that reason).
A funny thing is that this is not a problem for gtk applications. They use libnotify that uses GDBusProxy that does StartServiceByName call automatically.