| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
| |
Update NEWS.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
We're using error variable multiple times, and this may lead to problems
when trying to set it again. So let's just clear once it's used.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The activated action name is written to stdout and the notification is closed
when a valid action has been selected.
|
| |
|
|
|
| |
If an expiration timeout is set, the notification is not waited longer
than such time.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
It's not really an issue here, as we use a properly typed len, but
better not to use a deprecated and potentially dangerous API.
|
| |
|
|
|
| |
In future meson will check the run_command result by default, while it's
fine for us, it would cause our nicer error message not to work.
|
| |
|
|
|
|
| |
This reverts commit 1ad46301071856663735812a4dd7c15e6f054fd4.
As per: https://gitlab.gnome.org/GNOME/libnotify/-/commit/1ad46301#note_1434358
|
| | |
|
| |
|
|
|
| |
This avoids differences between IDs for separate builds of the
specification.
|
| |
|
| |
This reverts merge request !21
|
| |\
| |
| |
| |
| | |
Add README clarifying status of libnotify
See merge request GNOME/libnotify!21
|
| |/
|
|
|
|
| |
See discussions at https://gitlab.gnome.org/GNOME/libnotify/-/issues/20.
Based off https://gitlab.gnome.org/GNOME/libnotify/-/merge_requests/19
|
| |
|
|
|
|
|
|
|
| |
Right now notify-send will quietly return a successful exit status
even if showing the notification fails.
This commit changes the behavior to instead fail on failure.
https://gitlab.gnome.org/GNOME/libnotify/-/merge_requests/13
|
| |\
| |
| |
| |
| | |
Update documenation (generated man file) to express that plasma notification...
See merge request GNOME/libnotify!14
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
system will ignore timeout value when level is in critical mode
|
| |\ \
| | |
| | |
| | |
| | | |
notify-send: Support commas in icon filenames
See merge request GNOME/libnotify!15
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Do not cut off an icon filename (passed to -i) at the first comma
character. The original motivation probably was to support a list of
icon names in -i separated by comma. However, this has never been
implemented and the help text for -i also only mentions "an icon".
Hence, no functionality is lost by this change. In contrast, -i now
supports commas in icon filepaths.
https://gitlab.gnome.org/GNOME/libnotify/-/issues/16
|
| |\ \
| |/
|/|
| |
| | |
fix CI build stuck on TZ data config
See merge request GNOME/libnotify!16
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
when pushing a new commit, I noticed the CI build gets stuck on:
Configuring tzdata
------------------
Please select the geographic area in which you live. Subsequent configuration
questions will narrow this down by presenting a list of cities, representing
the time zones in which they are located.
1. Africa 3. Antarctica 5. Arctic 7. Atlantic 9. Indian 11. US
2. America 4. Australia 6. Asia 8. Europe 10. Pacific 12. Etc
Geographic area:
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Add notify-send manpage
Closes #4
See merge request GNOME/libnotify!6
|
| | |
| |
| |
| |
| |
| | |
Taken from Debian, converted to Docbook and fixed some issues.
Closes: https://gitlab.gnome.org/GNOME/libnotify/issues/4
|
| |\ \
| | |
| | |
| | |
| | | |
notification: use snap namespace and prefix whent launched inside snap
See merge request GNOME/libnotify!5
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
|/|
| |
| | |
Drop Autotools
See merge request GNOME/libnotify!11
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
MacOS linker does not support --version-script argument so we need
to only add it to ldflags when it is available.
|
| |
|
|
| |
Update NEWS.
|
| |
|
|
|
|
|
| |
Newer meson versions expect a relative path (to the includedir option)
there and reject passing an absolute path.
https://gitlab.gnome.org/GNOME/libnotify/merge_requests/8
|
| |\
| |
| |
| |
| | |
notify-send: allow passing colon as hint value
See merge request GNOME/libnotify!4
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
While some hints like image-path or sound-file supports parameters using the
file:// protocol, it's impossible to pass such hints to notify-send, because
it splits the passed argument so that it can have an unlimited number of colons,
while only 3 should be there (as per TYPE:NAME:VALUE format).
So, make `g_strsplit` to accept only 3 tokens as maximum, while pass the
remaining parameters all-together.
So now it's possible to do
notify-send -h string:image-path:file:///usr/share/icons/foo.png
|
