The PropertyNotify handling has been changed in the dropgtk branch to
ignore XEvents, when redrawing was unnecessary. But when the fullscreen
state of a window changes, we can't ignore the event, because it didn't
change the screen.
Additionally, there had been a mistake in the handling of the cur_screen:
The xctx.cur_screen field will only get updated, when the application is
visible and gets redrawn. Therefore, when a PropertyNotify event arrived
while the application had been hidden and the screens do not match
anymore, wake_up() will be called albeit being unnecessary.
Calling x_win_draw() when the screens change is also the preferable
solution over wake_up(), as there is nothing subject to change in the
queues when the displays change.
According to the docs in the GSourceFuncs, the timeout_ parameter can be
NULL. But when it's NULL, it would be equivalent to an invocation to
return -1 as timeout_ and FALSE as return value. This is exactly the
same, what we're doing if timeout_ is not NULL.
When receiving a PropertyChange XEvent, it's mostly because the focus of
another window changed to another window. This isn't actually neccessary
for dunst. We need the event only, to know, when the screens have
switched.
As redrawing the screen became more expensive with the drop of GTK3, we
have to ignore this event and only really redraw the window, when the
focus has moved to another screen.
As per discussion in #334 drop dependency on gtk3 and instead depend
only on gdk-pixbuf2 for icon loading.
The only gtk3 function used was gdk_cairo_set_source_pixbuf in order to
convert the loaded pixbufs into cairo surfaces for us to render. In
order to drop the dependency this step was bypassed by using pixbufs
export to png capability and importing it into cairo via a pngstream.
The commit 7f335b7 introduced, that specific notifications did not time
out properly. Although these had been internally closed already, X11
still displayed them.
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
There is no need save if the icon field should have precedence, as
setting raw_icon to NULL emphasizes the same.
Also freeing raw_icon saves unneccessary memory.
time(NULL) is vulnerable against timeshifts by NTP, timezones,...
g_get_monotonic_time() is not, but counts its in microseconds with the
gint64 datatype. To prevent any conversion bugs, all internal
timeformats are now using a gint64 and only get converted during import
or export (DBus notification arrives, configuration reading, age
threshold display).
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'
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
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.
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.
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.
