These aren't used anymore. Any notification which gets moved from
waiting to displayed, will have set the start field with the current
monotonic time.
So testing start == 0 won't ever succeed in
queues_notification_is_finished, as the tested notification is contained
in the displayed queue. So the start field never will be 0.
Also there's no semantics for start being 0 in dunst actually
implemented.
When using a format with a trailing % character, dunst ends in an
endless loop, searching for a % char, while pointing exactly with the
haystack on the % character.
Increasing the substring pointer will shift the pointer forwards onto
the actual NULL character and stop the loop.
In previous releases when a replace request came in with an id that
doesn't exist we created a new notification with it anyway.
This is used by some to imitate the behaviour of `stack_tag` and while
not recommended (as it will break if another notification gets assigned
that id) we want to avoid such subtle breakages without consideration.
This bug was introduced in d879d70da060ea78fe735d62249a0afdf3e61bc8.
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.
