* Move mouse_left/middle/right_click to global section
* Match the enum value style
* Ignore unknow mouse event
* Split copy-paste code into a function
* Fix typo
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
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.
Calculating the screen dpi on a per-monitor basis can cause
inconsistencies if multiple monitors with slightly different dpis are
used and in some cases it might not be the expected behaviour.
As such, the per-monitor dpi calculation was changed from a default
fallback to an opt in experimental feature and the default value of 96
will be used for the dpi if Xft.dpi is not set.
In the future, depending on how we decide to continue, we can either
move this setting in the global configuration section and fall back to
the X11 display dpi as the default or simply always use the per-monitor
dpi calculation. But to preserve backwards compatibility, this decision
can wait until the next major release.
Merge the allow_markup and plain_text settings into a single setting.
These 2 settings had a similar function, allow_markup controlled whether
markup was parsed or stripped and plain_text whether the notification
was escaped and displayed as is.
To cover all the possible combinations of the settings mentioned above
`markup` can take the following values:
full: The equivalent of allow_markup yes, plain_text no.
Passes the text straight to pango with minimal parsing. All valid
pango tags will be parsed.
strip: The equivalent of allow_markup no, plain_text no.
Strips the markup using string_strip_delimited. The parsing is
simplistic and if there are any unescaped '<' and/or '>'
characters it might get tripped and strip out actual text.
According to the GNOME notification specification, if a server
doesn't support markup(and we don't advertise that we do if it is
turned off) it should be stripped clientside, so this setting
should rarely be used. It is mainly left in for compatibility
with broken clients that don't follow the specification.
no: The equivalent of allow_markup [yes/no](any value), plain_text
yes.
Makes the notification content be rendered as plain text
regardless if it contains markup. Any Markup will be shown as
regular text.
Markup inside 'format' will still be parsed regardless of what markup is
set to.
Closes#279
The current "allow_markup" setting will simply strip any markup from the final
notification, which includes formatting elements. On top of that, literal
[<>&..] symbols are not quoted before are being passed onto pango in several
places, resulting in stray error messages.
This patch fixes allow_markup to correctly strip markup only from the incoming
notification, not from the format.
You might also want to treat incoming messages as literal text (supplied by
un-aware programs), in which case you need to properly quote the text before
it's processed by pango. A new setting is introduced, called "plain_text",
which forces incoming messages to be treated literally.
allow_markup/plain_text are complimentary to each other.
The new rule actions allow to narrow down the handling to a specific block,
achieving notification Zen.
The following is done in this patch:
- Fix ruleset initialization in config.def.h.
- Introduce new allow_markup/plain_text actions in the rules.
- Fix handling of allow_markup to strip markup from summary/body only,
preserving format's markup.
- Fix broken string functions (string_replace_all didn't handle recursive
replacements correctly).
- Fix quoting of other literal fields (icon name/appname).
- Fix handling of ignore_newline as well (applied only on summary/body).
- Dunstrc update with the same previous defaults.
