Currently triggers only the latest notification. TODO: implement it
either with ActionsAll or more favorable: with an optional paramter,
which should trigger only the action of a single notification.
The problem currently: I have got no ability to check the DBus docs, as
I'm on a bad internet connection.
I'm not sure whether this case can happen in the wild, but if
artifically exercising the condition, I noticed it behaves
poorly. Specifically:
* The error_name parameter must be a valid D-Bus error name. It seems
conventional to set this to "org.freedesktop.Notifications.Error".
Without this change, the following error is thrown:
CRITICAL: g_dbus_method_invocation_return_dbus_error: assertion 'error_name != NULL && g_dbus_is_name (error_name)' failed
* Previously execution would continue even though the notification did
not decode, causing essentially a null pointer exception later.
Adds a return for this case.
* With those two things fixed, this case seems relatively silent -
"notify-send" invocations succeed even if the condition for the if
is "true". So, I added a warning log to indicate that this case is
occurring
Currently, we just skipped the notification comparison, if the
notification had a raw icon attached. This is a bit counterintuitive.
Calculating a checksum of the raw icon's data is the solution.
For that we cache the pixel buffer and introduce a field, which saves
the current icon's id. The icon_id may be a path or a hash.
So you can compare two notifications by their icon_id field regardless
of their icon type by their icon_id field.
Just recently, I started using g_return_val_if_fail as a brief assertion
checker. It'll also exit the function with a specified return value.
But actually this introduces some weird behavior. It's configurable by
environment variables and it'll print out a log message, if the
expression didn't validate properly. But some of these assertions are
actually ment to be silent.
Using a simple macro makes it simple to structure the assertions and its
return values in a block at the start of a function or anywhere else.
The notification spec says, that a notification gets invalidated when
closed. So the client won't listen anymore to ActionInvoked signals and
won't listen to NotificationClosed signals.
Remembering the actual status of the notification helps the standard and
makes the behavior clearer.
The blame reveals commit 820cfe73, which introduced printing of
notifications similar to notification_print(). The fflush call is still
left over since porting the printfs into their dedicated method.
As notification_print() is called after this fflush() call, it's not
necessary anymore.
When the DBus name lost function is called, either the whole DBus
connection is lost, or another rivaling FDN daemon acquired the name.
Without enough experience, this is impossible to trace back and examine
further.
To make it easier for new users, dunst prints out the PID of the
process, which currently acquired the FDN DBus name.
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.
