Previously config lines like
[rule]
script = mail -s "New notif"
were only possible to get written with additional full quotes,
which makes no sense in command line expressions.
Parsing the arguments with g_shell_parse_argv is more safe than just
splitting it by spaces. Also this allows to pass values with spaces to
the browser command.
When executing dmenu, the current notifications get "locked", by setting
their timeout temporarily to 0 and referencing them. So the notification
won't get closed (exept forcefully) and won't get freed while dmenu is
opened.
This is currently pointless, but as the dmenu call will become threaded,
it's necessary later.
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.
Focus events do not mark any change in state of the notifications so
calling wake_up as a response is a wake of CPU cycles. Instead treat
them like PropertyNotify and only redraw if we need to change monitors.
Before this commit when using Dunst with multiple displays and
follow mode mouse/keyboard on a new notification (when no other
notifications are shown) a black window flickers up at the screen where
the last notification was shown.
By calling draw() before x_window_show the new window position will be
calculated and the window will be moved there before the window is shown
and thus remove the flickering.
When the display queue had is full and a new notification would come
in, new notification wouldn't get shown until a currently displayed
notification would timeout.
Even if the notification would have been shown on top of the displayed
queue. So e.g. if the displayed queue would have been filled with
"normal" urgency notifications, an incoming "urgent" notification would
have been delayed.
To let those more important notifications through, the tail of displayed
and head of waiting are swapped on every update if necessary.
