My usecase is that I don't want to get notified for every new song
that plays (it's distracting), but I do want to bring them up via the
notification history.
I'm not sure whether this case can happen in the wild, but if
artifically exercising the condition, I noticed it behaves
poorly. Specifically:
* The error_name parameter must be a valid D-Bus error name. It seems
conventional to set this to "org.freedesktop.Notifications.Error".
Without this change, the following error is thrown:
CRITICAL: g_dbus_method_invocation_return_dbus_error: assertion 'error_name != NULL && g_dbus_is_name (error_name)' failed
* Previously execution would continue even though the notification did
not decode, causing essentially a null pointer exception later.
Adds a return for this case.
* With those two things fixed, this case seems relatively silent -
"notify-send" invocations succeed even if the condition for the if
is "true". So, I added a warning log to indicate that this case is
occurring
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.
A bug, introduced in #576. If alignment isn't set in the config, the
settings would print a warning about an invalid value. But actually it's
just the default string, which can't get parsed.
The fallback value should get handled by a false return value and not by
the option_get_string's default value.
Changes all string parsers to have a the almost same interface while
also having a proper return value, which indicates success of the
parsing process.
Just recently, I started using g_return_val_if_fail as a brief assertion
checker. It'll also exit the function with a specified return value.
But actually this introduces some weird behavior. It's configurable by
environment variables and it'll print out a log message, if the
expression didn't validate properly. But some of these assertions are
actually ment to be silent.
Using a simple macro makes it simple to structure the assertions and its
return values in a block at the start of a function or anywhere else.
As already noted in the code comment, we all knew that the in memory
conversion to a PNG stream is a cumbersome technique. But it was worth
to remove the GTK dependency.
After finding out, that gdk_pixbuf_new_from_data can actually use a
GVariant and share its memory without allocating new memory, I poked
the cairo docs for a similar technique.
There is cairo_image_surface_create_for_data, which would achieve the
same, but cairo uses another color byte order. So we have to manually
copy and reassemble the bytes.
It may look like a big rise in complexity, but actually, it's straight
forward copying pixel by pixel and changing the byte's order.
And the gdk_pixbuf_to_cairo_surface is 33x faster.
The log messages are useless during general and automated testing. But
while developing tests, the warning messages might be an easy debugging
option to check why one's own test currently fails.
This implies, that memory will only get freed, if the whole test method
is gone through. In case of failure, memory leaks aren't important. But
it's crucial not to fail with a segfault just for an assertion.
Fixes#580
Before, it only did test for `ASSERT_FALSE` both times. So a raw_image
wasn't guaranteed to be a condition to falsify the return.
Using the single field function, will test for both cases.
When using clang, this will create a race condition between
clang/gcc builds. Coveralls will take the first one. As GCC and clang
are counting line coverage differently, coveralls regularly fails.
While running under valgrind, it may take over 30 cycles in the loop to
wait for a running GTestDBus instance. So we have to increase the
waiting time.
Waiting a whole second will change the signal/noise ratio and will only
fail, if there's really a problem with the GTestDBus usage.
And as we're sleeping 500us in every loop, we usually get a super fast
response, too.
