so that dunst binaries build in a reproducible way
in spite of indeterministic filesystem readdir order
See https://reproducible-builds.org/ for why this is good.
To replace all occuring format strings inside the msg, replace_all had
been used previously. This leads to buggy behavior, if a format string
occurs in the replaced text, as the format string will get replaced
again under certain conditions.
Introducing a pointer, which skips the already replaced parts, will
prevent doubly replacing format strings from content.
Fixes#322
To achieve a consistent scheme, all stars of the
pointers should be on the side of the variable and
not on the side of the type.
wrong: char* a
wrong: char * a
good: char *a
This commit is generated by the following sed command
with manual fixes of all false positives.
find src \( -name '*.c' -or -name '*.h' \) -print0
| xargs -0 -n1 sed -i
's/\([a-zA-Z]\+[-_a-zA-Z0-9]*\)\s*\*\s\+
\([a-zA-Z]\+[-_a-zA-Z0-9]*\)/\1 *\2/g'
Move the iter pointer to the next item before doing any logic that might
result in exiting from the current iteration of the loop since it would
cause the same notification to be processed repeatedly resulting in an
infinite loop.
Fixes 362.
If the transient hint is set on the notification, it should only be
valid as long as it shows up. So the pushing it to the history
makes no sense.
As it's no problem to change this individually by the rule system,
it's a sane default for history_ignore to default to the transient
option.
When closing a notification in check_timeouts, iter will get removed
of the list and therefore iter->next is NULL at the end of the
loop. This requires calling check_timeouts again.
Shifting iter to iter->next before removing the notification, we can
avoid recalling check_timeouts and avoid processing the already
processed list again.
Existing configurations will continue to work but now print a warning.
New, icon_path option takes precedence if both options are used.
If icon_folders option is used, its usage string also appears in --help
output.
When a notification contains both a raw icon and an icon path according
to the GNOME notification specification the raw icon should take
priority over anything else.
If, however, a user uses the new_icon rule to set a custom icon on a
notification, that rule overwrote the icon path and not the raw icon
and as a result the raw icon was displayed in place of the user
specified one.
As a simple fix, a new icon_overridden boolean was added to the
notification struct indicating if a custom icon has been set. If so, the
icon path should take priority over the raw icon.
Fixes#339
