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
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.
We may need to use them in various places, so there's no point to repeat
the same in multiple places, this way we can also use some shortcuts for
non-snap setups.
We used to just add it again, to eventually figure out that the file
did not exists, but may not work properly in some scenarios.
Also always fill the path_filename when using a file-name only, as that
may be refer to something under the SNAP path, and in such case we want
to try check if that exists before giving up.
When a non-relocatable application is packaged as a snap, its resources
will be visible under `${SNAP}`. We can discover these resources by
probing paths that are given to us and trying the same path under
`${SNAP}` if the probe fails.
Snap packages have desktop files namespaced by the snap name. This name
is available inside the snap environment as `${SNAP_NAME}`. Also probe
desktop files and try this form of mangled name if the referenced
desktop file is not found.
Using GFreeFunc instead of GDestroyNotify was a mistake, but
(scope async) is even a bigger mistake (one that can crash apps,
if an action is invoked multiple times)
https://bugzilla.gnome.org/show_bug.cgi?id=702390
When a daemon like gnome-settings-daemon has multiple plugins, if a plugin uses
notify_set_app_name() then subsequent notifications get the wrong
'Application name' in the gnome-shell persistent message tray.
This new function is per-notification and is thus allows us to set a custom
application name without overwriting the application name stored by notify_init().
https://bugzilla.gnome.org/show_bug.cgi?id=648947
Due to an oversight in the condition, has_nondefault_actions is
never set to true. Not sure this makes a _big_ difference in practice.
http://trac.galago-project.org/ticket/194
Marco Trevisan (Treviño)
Corentin Noël
Iain Lane
Evan Nemerson
Giovanni Campagna
Matthias Clasen
Richard Hughes
William Jon McCann
Martin Pitt
Jonathan Matthew
Javier Jardón
Guillaume Desmottes
Christian Persch
Bastien Nocera
Aurélien Gâteau
Christian Hammond