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
The timeline of this issue is as follows:
In 7a094bc a call to XClearWindow/XFlush was added as part of RGBA
support.
Afterwards, I noticed that there is some noticeable flicker while
redrawing for large notifications, so I foolishly removed both of these
calls without considering the full effects.
As a result when redrawing notifications 'stack up' with each-other.
After a testing it seems that the XFlush call that was causing
the flicker is not necessary and XClearWindow works without it.
Fixes#728
This reverts commit 7a094bc702149104cd4049281a7dd9ed0ab76c89.
This commit caused a flicker effect every time the window was redrawn,
reverting it for now.
The returned node was theoretically read-only however all the other
nodes accessible do not inherit the qualifier. Since none of the glib
functions use const with Glib, even the read-only ones. There's no use
in having it.
This resolves the warning about g_list_nth_data.
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.
In dwm and similar window managers, it's common to often have empty
tags, and navigate to them with the intent to create clients there. If I
navigate to one of those empty tags with a dunst notification visible
and follow=keyboard set, the notification warps over to the default
screen. If I then open a client, it then warps back, which is pretty
jarring.
This is mostly an artefact of the implementation of follow=keyboard --
if we fail to get a focused window, we use the default screen. However
this case isn't necessarily really a "failure" on window managers like
dwm where it's a common occurrence to end up with no clients on the
screen, whereas that would be significantly rarer on (say) GNOME or KDE.
A guess that's more likely to fit user expectations is falling back to
where the mouse pointer currently is, since this indicates the currently
focused monitor that the window manager would create a client on. This
avoids warping back to that monitor again when a client is created.
