When an application is running from a snap or a flatpak, libnotify
should just work as a FDO Portal Notification wrapper.
As per this, make the library to try use the portal API in sandboxed
applications, by emulating the needed missing pieces.
Not everything can be achieved 1:1, but it's just safer to use in such
contexts.
It's almost 10 years old, so I think we can safely depend on that to
support the features we're optionally depending on, plus the ones we're
going to add
An application under snap confinement won't have a way of escaping from
it, so we can just initialize the snap variables at the global notify
scope once and just re-use them when needed.
Starting with d0778595, we access the Notification object after the
NotifyActionCallback; some clients (eg, Electron) have historically
unref'd the object at the end of the NotifyActionCallback. They probably
should not have been doing so, but this hotfix adds an additional ref
before and after the callback so that we don't break existing code.
Fixes#25
Per:
- Discussions on #release-team
- No response to email to mccann in over 10 days
- Email response from chammond confirming he should no longer be listed
as maintainer
See also: afef1e98Closes: #14
In case a transient notification is requested but persistence is not
supported, it's not an error but it is useful to show a debug message
to clarify that.
Notification actions can now be activated with an activation token
containing platform data. So update the notification-spec to include
latest version of the specification, and expose the activation token
during an action activation.
Not to change the API, by modifying the type of NotifyActionCallback
it's just better to provide a function to fetch the activation token
during activation only, so that this can be retro-compatible.
Reference: https://gitlab.freedesktop.org/xdg/xdg-specs/-/commit/b9a4700
Support printing and overriding notification ID, so that it's possible
to replace a notification that is currently showing with an updated
content.
Based on patch as provided by Paul Collins in the following bug
report:
https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135/comments/8
Co-authored-by: Marco Trevisan (Treviño) <mail@3v1n0.net>
Fixes#19
Snaps use desktop IDs based on the snap name and the application name
inside the snap, so if we're in a such container, we need to compute the
desktop-entry using those values. We can figure them out from the snap
cgroup they're in.
In such case, don't even try to use the GApplication ID as that is
likely wrong in a snapped environment.
Marco Trevisan (Treviño)
Logan Rathbone
Patrick Griffis
Ben Blain
Matthias Sweertvaegher
Paul Collins