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.
The frame and experimental sections are currently used for some settings
related to frame colour and experimental features respectively and as
such should not be parsed as rules.
Practically rewrite the entire manpage to focus more on the
configuration rather than the command line flags. Additionally, expand
more on how many of the settings work and on some of the less documented
functions (e.g. rules).
Make every setting be overridable from the command line using
-setting_name. Previously, some settings had shortened command line
flags (e.g. -fn instead of -font) which made the command line arguments
confusing.
Hardcoding a DISPLAY variable is a bad idea because it means that dunst
will only run on X11, and only for that specific configuration.
FWIW, this actually applies to any desktop app run via systemd:
1. `DISPLAY` should be set by `systemctl --user set-environment` elsewhere.
2. `DISPLAY=:0` is not universally valid.
3. This breaks dunst if attempting to run wayland, and requires manually
starting it (eg: not via systemd), or editing the file.
Expose events, according to the X11 documentation, signify when the
contents of a window region have been lost but until now we have been
ignoring this event for unknown reasons.
Handle this event by redrawing the window entirely. While this is not a
perfect solution, the optimal one would be to only redraw the
region that was lost, it's simpler to implement currently and better
than losing the contents of the window entirely.
Since currently the multimonitor extension support is a compile-time
argument, there is not much we can do to recover from not being able to
initialize RandR other than print an error and exit.
Make the class in the XrmGetResource call be the same as the resource
name we are trying to retrieve, "Xft.dpi". Nowhere in the documentation
it is mentioned that the class name can be NULL so it is better to be
cautious and set it to a value that is unlikely to affect anything.
Since we only use sudo for installing packages, start using the apt
travis addon for the installation in order to allow container-based
builds to be used for testing dunst which should theoretically have a
faster boot time.
