Currently, we just skipped the notification comparison, if the
notification had a raw icon attached. This is a bit counterintuitive.
Calculating a checksum of the raw icon's data is the solution.
For that we cache the pixel buffer and introduce a field, which saves
the current icon's id. The icon_id may be a path or a hash.
So you can compare two notifications by their icon_id field regardless
of their icon type by their icon_id field.
The notification spec says, that a notification gets invalidated when
closed. So the client won't listen anymore to ActionInvoked signals and
won't listen to NotificationClosed signals.
Remembering the actual status of the notification helps the standard and
makes the behavior clearer.
The hints given via DBus are not constants. Therefore the color fields
have to get freed during notification cleanup. As it's not possible to
disinguish, which field is constant, we have to duplicate the settings
on assignment.
While the notification spec allows tags like <a href="...">...</a> and
<img src="..." alt="...">, pango cannot parse these tags and therefore
these tags should be removed before passed to pango.
Also the method notification_extract_markup_urls is not needed anymore,
as markup_strip_a can return URLs optionally.
This implies, that URL replacement is now indicated via show_indicators
for URLs and the dmenu string is in the format of
'[text between a tags] URL\n'. This is similarly handled for images,
too.
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.
Move all id-changing functions out of notification_init and handle this
in queues.c
Also use stack_duplicates in combination with replacement of
notifications correctly. Fixes#404 (issue not found)
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).
Previously, notifications had been replaced by removing the notification
out of the displayed/queue lists, redrawing the window and then adding
the new notification into the queue. This produced a flickering in
dunst.
By avoiding the overhead of closing and opening the window (simply
replacing the datapointer of the list), the flickering disappears.
To replace all occuring format strings inside the msg, replace_all had
been used previously. This leads to buggy behavior, if a format string
occurs in the replaced text, as the format string will get replaced
again under certain conditions.
Introducing a pointer, which skips the already replaced parts, will
prevent doubly replacing format strings from content.
Fixes#322
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
