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.
The generated notify-features.h header lives in builddir, which means it
does not exist in srcdir, where glib-mkenums will look. It also contains
pre-processor symbols only, so it's not really useful.
As we removed it from the list of headers to be scanned by the
introspection parser, we also need to update the files rules for that.
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
The lazy initialization from commit 3dc04fa caused a small regression: When a
process would init and uninit libnotify without ever sending a notification,
_proxy was still NULL, which caused an assertion
(process:20953): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
Bug-Ubuntu: https://bugs.launchpad.net/bugs/570462
Instead, open ourselves through GModule, and check whether
we have all the GTK+ and GDK functions required for us to
work correctly.
This means that the front-end application cannot rely on
libnotify linking against GTK+, which would only be a problem
for edge-cases.
https://bugzilla.gnome.org/show_bug.cgi?id=622550
Marco Trevisan (Treviño)
Corentin Noël
Jan Tojnar
Iain Lane
Florian Müllner
Emmanuele Bassi
Evan Nemerson
Giovanni Campagna
Matthias Clasen
Colin Walters
Javier Jardón
Richard Hughes
William Jon McCann
Emilio Pozuelo Monfort
Martin Pitt
Jonathan Matthew
Guillaume Desmottes
Christian Persch
Jonny Lamb
Bastien Nocera