Sometimes these parse functions can have other side-effects such as the
sepcolor one which defaults to a custom color string if the value is
unknown. If the string is empty all of these functions should fail to
allow for the default to be used.
See #649 for details
IceWM does not send PropertyNotify when exiting fullscreen. As a
band-aid solution also re-check the fullscreen status on ConfigureNotify
events. We're receiving them already so a few extra checks should not be
noticeable in any case.
Fixes#613
Draw should not be called when there are no notifications in the queue.
This for unknown reasons causes a crash the next time we attempt to get
the currently active window with a BadValue error from
XGetWindowProperty.
Fixes#630.
In `x_parse_geometry` we modified the global settings struct for
negative width instead of updating it in the struct that is currently
being constructed.
As a result the negative_width field was always false as it was being
overwritten by the struct assignment after the functions return.
Fixes#628
Quoted values can still have a trailing comment that we need to remove
before calling `add_value`. Otherwise, when trying to strip the quotes
from the value `string_strip_quotes` only looks at the end which
is inside the comment and so it won't find a matching end quote to
strip.
Fixes#626
The width_set field is true if the width is set in the geometry setting,
in other words if a specific (or dynamic) width is set or we want the
notification to cover the whole screen.
In order to check if a specific width is chosen we need to also exclude
dynamic width, meaning the width field has to be non 0;
Fixes#614
PropertyNotify events are used primarily to detect active screen changes
when follow mode is used but now we also need them to receive resource
manager events in order to update the dpi value.
When changing values with xrdb on the command line, an XEvent is
triggered on the "RESOURCE_MANAGER" atom.
But xlib just doesn't care. XResourceManagerString() will still report
the old values. Also XrmGetDatabase() won't help out.
So, when we receive a PropertyNotify for the resource manager atom, we
have to manually query its contents, convert it to a DB and replace it
in the display object.
This allows, that any method just can call XrmGetDatabase() and get the
latest values.
This allows to update the DB on the xctx.dpy object. Crawling the string
from xctx.dpy will always return the xdefaults string, which represents
the defaults from the initialisation, but not with any other updates.
The Xft.dpi value is one way to set the dpi of the X11 display. Querying
this value requires much overhead. Therefore we have to cache this.
Previously we did just query it at the beginning and ignored further
changes.
As there is no native signal to catch a change in its xrdb value, we
have to rely on the root window's PropertyNotify event and filter there
the RESOURCE_MANAGER atom.
This will get hooked up later.
When changing the DPI via xrandr --dpi <DPI>, xrandr will send a
RRScreenChangeEvent and the DPI value should get adjusted.
Falsely, we thought randr_update() would catch up and query the right
monitor values. But nothing changes, because we query the
XRRMonitorInfo. The monitor info contains the real physical width and
height of the monitor's screen.
But xrandr --dpi only changes the - let's say - virtual screen size of
the virtual overall screen (and therefore changing the DPI to the
matching value).
Important commands to understand:
- Changes dpi of the virtual screen
xrandr --dpi
- Gives info about the "virtual" screen size (used by DisplayWidth)
xdpyinfo | grep -B1 resolution
- Gives info about the "physical" screen size (used by XRRMonitorInfo)
xrandr -q
I know, that I'm probably not right and might not understand the topic
in its full size yet[0]. But I'm 100% sure, that the terms "monitor",
"screen", "screens", "output" and "display" do not have a consistent
naming scheme.
[0] https://twitter.com/dechampsgu/status/857924498280124416Fixes#382
If n < screens_len, screens_len did not get updated. So boundary
checks wouldn't catch, if screens between n and screens_len are
accessed. This will prevent such an error type in the future.
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.
