Before this commit when using Dunst with multiple displays and
follow mode mouse/keyboard on a new notification (when no other
notifications are shown) a black window flickers up at the screen where
the last notification was shown.
By calling draw() before x_window_show the new window position will be
calculated and the window will be moved there before the window is shown
and thus remove the flickering.
For notifications without any timeout, ttl can't be positive.
So when, show_age_threshold is active, dunst won't wake up, if there
are only notifications displayed without any timeout.
While the rule's field will get checked for a NULL value, the
notification's field won't get, as it's assumed to be non-NULL.
This is problematic, as there can be some corner cases, where the
notification's field is actually NULL.
Fixes#536
Created a wrapper script to customize theme variables (colors,
fonts, etc) according with your X resources file (~/.Xresources).
As dunst is not a X exclusive notification daemon, this script
could be a workarround to solve this.
Related with: #357
* 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
All XEvents only got logged with their IDs. It makes more sense to write
out the XEvent's name. Also, writing that we received an XEvent and then
logging again, that we ignored it, makes no sense.
As the get_pixbuf_from_file should retrieve a file's content, it
shouldn't fail silently, if the file isn't there.
For codepaths, which don't use the `icon_path` to search for a given
icon, it gives a clearer error message.
notify-send uses g_strcompress on the body of the notification to
replace escape chars (e.g. newline). Since dunstify is supposed to be a
drop-in replacement we should match that here as well.
When using round corners, the shape_gc in x_win_round_corners never got
freed. This created a memory leak in x11 itself and let the X process
create more load while becoming sluggish in some situations.
From the docs, XFreeGC actually could return an int and could throw a
BadGC error. Neither of them are important to catch in our situation:
- Having a look into the Xlib sourcecode, XFreeGC returns always 1.
- As we don't overwrite the shape_gc or do any other destoying calls,
the BadGC can't happen in this code.
The icon_path has no point for searching an absolute filename. It was
actually meant to avoid the complex lookup algorithm of the icon theme
spec. And the iconname in this case should be actually just the icon's
basename when searching the path.
Concatenating icons like `~/testimg.png` with all icon paths has no
point and also an additional suffix has no point.
