The notification spec has no concept of disallowing closing notifications,
so to make the ignore_dbusclose 'compliant' we choose to lie to the clients
that the notification is actually closed, but keep it open.
To do this, we send a NotificationClosed signal back (via signal_notification_closed
which also call notification_invalidate_action)
g_list_nth_data was used to query the notification list, but in the code
it was erroneously assumed that a GList object was returned rather than
a notification.
One of the many pitfalls of generic pointers...
Fixes#727
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.
