The `dimension_t` struct was used in many different places and even held
on the geometry info at some point which is counter-intuitive as it's
best to have each struct serve a single purpose.
Due to the way Xlib handles errors XRRGetMonitors will cause dunst to exit if
the server doesn't support version 1.5 of RandR. The check for null is
effectively dead code but in theory the number of monitors can be < 1 so treat
this as an error. Change the code to fetch the RandR version and fallback if
the version is less than 1.5 when getting monitors.
This fix was brought up by @SteveJones on GitHub
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'
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.
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.
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.
Previously, we were getting screen info every time we tried to move the
window. To improve the situation, information about the available
screens is initialised once when dunst starts and further behaviour
depends on the compile-time options used.
If Xrandr is enabled, screen information is updated when an
XRRScreenChangeNotify event is received, meaning only when the screen
layout changes.
If Xinerama is enabled, screen information is only updated on startup.
This behaviour might be changed later.
If none are enabled, then dunst assumes only one screen and ignores all
multi-monitor options.
Since we are adding Xrandr support to allow for automatic dpi detection,
split screen handling code into a new file as part of the effort to
simplify x.c
