The signal_notification_closed function is called even when a
notification has been pulled from history and re-emits the
NotificationClosed signal, this can confuse clients since multiple such
signals are not accounted for in the spec.
Distinguish between a failure to connect to DBus and a failure to
connect to the actual FDN DBus path.
This is possible, because `on_name_acquired` gets its DBus connection
passed as a parameter. If this parameter is NULL, there is no connection
established and the DBus name is not lost, because another notification
daemon is running.
When having a long running notification and an additional two shorter
notifications arrive. The short notification, which times out later,
does not timeout correctly and gets flushed only, when the long running
notification is flushed or a Focus* XEvent is sent.
The commit 7f335b7 introduced, that specific notifications did not time
out properly. Although these had been internally closed already, X11
still displayed them.
As GApplications expose their icon via image-path hint and not via the
actual app_icon field, GApplication icons haven't been displayed before.
According to the notification spec, image-path hint should also override
the app_icon as follows:
1. image-data hint
2. image-path hint
3. app_icon parameter
If specifying --icon with UTF-8 characters, the g_option_context_parse
fails with an invalid byte conversion. The solution is to set the locale
explicitly.
For more info, see the GLib issue tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=737137Fixes#443
Print the notification id, if requested, before blocking to catch action
return or NotificationClosed signal since once of those events happens
the program will exit without further action, bypassing the id printing
logic.
Notification spec prohibits to reuse notification IDs (unless uint32 is
exhausted). Therefore returning the same ID twice must not happen.
Sending a signal, that the old notification timed out makes most sense.
It wasn't closed by the user, nor by a CloseNotification call either.
When we stack notifications, no interaction happened (the equivalent
of timing out).
Due to the way Xlib handles errors XRRGetMonitors will cause dunst to exit if
the server doesn't support version 1.5 of RandR. The check for null is
effectively dead code but in theory the number of monitors can be < 1 so treat
this as an error. Change the code to fetch the RandR version and fallback if
the version is less than 1.5 when getting monitors.
This fix was brought up by @SteveJones on GitHub
There is no need save if the icon field should have precedence, as
setting raw_icon to NULL emphasizes the same.
Also freeing raw_icon saves unneccessary memory.
