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
* 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.
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.
As it currently stands notification_init uses xctx.color to initialize
the notification colors which means that it depends on x11 having been
previously initialized and crashes otherwise. This bug was introduced in
04b327f where draw_setup() was after the startup notification was
created.
As a temporary fix the notification creation was moved under draw_setup
but for a long term solution we should look into removing these xctx
dependencies.
According to the glib docs we should use g_source_add_unix_fd rather
than g_source_add_poll. Additionally, this helps us with memory
management since we don't have to handle the allocation of dpy_pollfd.
Move the code to register the x11 event source under x_win_create so
multiple windows can be created and be properly registered as the event
source.
One more missing piece is that the callback functions are still using
the global win variable and not getting the window from the source.
Move the double-buffering implementation and the x_win_call move into
x.c so we only need to call x_display_surface for each draw.
This isolates all uses of the cairo context and root surface outside of
x.c which will help to add support for other display servers.
Move the main window reference from xctx to draw.c and at the same time
make each X11 function that modifies the window require the pointer as a
parameter. This makes it easier to implement features that require
multiple windows.
According to glib docs the dispatch function should be G_SOURCE_REMOVE
or G_SOURCE_CONTINUE. Since this was worked properly until now I assume
we were lucky enough that true == G_SOURCE_CONTINUE but it may not
always be the case.
Subscribe to receive window creation events on the root window and raise
the window when that happens to ensure dunst is on top.
We do not raise the window when another override redirect window is
created to avoid being on top of things like screen lockers.
Fixes#160
Rather than calculating the width of the subsurface we are drawing on
everywhere simply add a return pointer to render_background.
This commit also fixes a bug where the text and icon where drawn more to
the right than usual (according to frame_width) which was caused because
we added the frame_width to the draw position while we are drawing in a
subsurface that already accounts for it.
