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
There is no need to have a separate VERSION file in release tarballs,
having the version in config.mk directly allows for a proper fallback in
case the git repository and the version file doesn't exists. The most
important example of this is the tarballs that github creates on every
release.
Since the behaviour of dunst in the last release was to display icons
as-is, we should try to preserve backwards compatibility as much as
possible. This commit may be reverted in the next major release.
If the per-monitor dpi feature has been enabled it shouldn't be overridden
just because an Xft.dpi value is set, it's possibly for other programs
that don't have such a feature.
Since after the release a lot of downstream users will not be building
from source, it makes a lot more sense to have an option to fall back to
the Xinerama extension for those that are still on systems that do not
support RandR.
While it's not the best solution, it should cover most use cases where a
custom format on the progress value is required. If any further
customization is needed, the only current alternative is to use rules
to override the format.
Closes#273
Displaying too heavy notifications can DoS dunst. For example bad
programs, which pipe raw image data into the notification.
Limiting the maximum character length to 5000 circumvents this.
5000 should be ridiculously high to prevent DoS while still not
truncating all correct notifications.
Bounce was functionally removed in
b2883b213342c912a76329bb8f6c179ea3451ae5 during the transition from Xft
to Cairo without any mention. There is no use to keeping it in the example dunstrc
and storing the value in the code,
This commit will probably be reversed if and when bounce is
re-implemented.
Rearrange the settings in the example dunstrc and the manpage into broad
categories according to the part of the program they affect: Display,
text, icons, history and misc.
There is no reason for the frame settings to have their own section
since it's not an area that will be expanded upon. Move them to the
global section to be consistent.
A middle click on an notification with a single or default action will
invoke it. If there are multiple actions and no default, the context
menu is opened. If there are no actions, proceed similarly with URLs.
