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.
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.
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.
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
x.c has grown into an unmaintainable blob. Moving it in its own
subdirectory is the first step to splitting it into submodules each of
which will have a well defined job so that a lot of the code can be
abstracted to improve readability and make it much easier to maintain.
This process will be done one small part at a time only when we need to
change significantly change a part of the file, there is no need to
break what already works.
If Xft.dpi value is not available, auto-detect value based on monitor using randr provided sizes.
Disable Xinerama and enable randr by default.
Also update dpi everytime the monitor changes.
When checking for the markup value in rules, an empty string was
specified as the default value so it can easily be checked if the actual
config value was empty or not. While that string got strdup'ed in the
ini_get_string call, it was only freed if the length > 0, effectively
leaking a tiny amount of memory.
Change that behaviour to use a NULL check instead to avoid leaking
memory.
Because "&" is not the last character to be unescaped, it is possible that
the lines for "<" and ">" expand some things they shouldn't.
For example, "&lt;" should become "<", but instead it becomes ">".
While this is unlikely to appear naturally in a notification, it is wrong.
This turns a hard-to-understand nested if{} chain into a simple switch
statement, and pulls some code out in to utility functions.
This is strictly a code-organization change, and should contain no
functional changes.
If dmenu didn't return anything we returned out of the function without
calling `waitpid` to collect the childs exit code, leaving to the child
process to be left as a zombie indefinitely. This commit makes `waitpid`
be called before the return checks are done.
When generating the list of urls to pass to dmenu, string_append with a
newline as a separator was called unconditionally. This caused a newline
character to be added for each notification even if it didn't contain
any urls, leading to empty items in dmenu.
Fixes#300
A lot of error reporting used a simple `printf` call which by default
prints to stdout. This was changed so that all error reporting is done
by an `fprintf(stderr, ...)` call.
It doesn't make much sense to print usage into to stderr. What's more is
that it prevents users from easily piping the output to other
programs(i.e. grep)
According to the glib memory allocation documentation, if any memory
allocation calls fail the application will be terminated so there is no
need to check if the call succeeded.
'True' and 'False' are defined in Xlib.h
Since we use stdbool boolean 'true' and 'false' definitions in several
places, it's best not to mix boolean macros. So in the sake of
consistency switch to using the stdbool macros project-wide.
To load each line of the configuration file we were previously using a
simple buffer of length BUFSIZ. BUFSIZ is a macro provided by glibc as
the 'recommended length for a buffer'. But since one of our users
encountered a situation where really long config lines were necessary
it's time to change that behaviour.
This commit changes the line reading from using fgets with a character
limit of BUFSIZ to simply using getline.
We initialize the buffer pointer to NULL since getline will
automatically allocate a big enough buffer for us if it's passed a NULL
pointer. After that we pass the same buffer pointer again since,
according to the getline manpage, getline will also call realloc on the
buffer if necessary. Which means the only thing we have to do is call
free() at the end of the parsing process.
Fixes#294
string_to_argv parsing was very simplistic and didn't properly handle
quotations. Since we are already using glib, g_shell_parse_argv serves
the same purpose with much better parsing and error handling.
Setting markup_mode to -1 might not work since in some implementations
enum might not be signed. For convenience, add a new enum value
`MARKUP_NULL` to serve the same purpose.
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
