this impacts only colors from which we compute Cairo colors, not the
rendered pixel buffers themselves, which were already and remain
ARGB32.
this makes Wayland and (24-bit) X11 use the same representation of
colors, fixing bugs when both backends were enabled.
we should still eventually switch to a backend-independent color
representation, because there are no guarantees of which pixel format
X11 will use (it isn't alway ARGB32) and backends like ncurses have
their own color representation; in most code we just hope the
unsigned long will be interpreted by the same backend as wrote it.
* Add mouse events.
Signed-off-by: Tin Svagelj <tin.svagelj@live.com>
* Rename MOUSE_EVENTS flag to BUILD_MOUSE_EVENTS.
Signed-off-by: Tin Svagelj <tin.svagelj@live.com>
* Update NORM_ERR func argument from std::string to char*
Because func was previously char* I forgot to update NORM_ERR function
argument to `func.c_str()` not that it's std::string.
Previously func was pointing to std::string memory that was freed at
assignment.
Signed-off-by: Tin Svagelj <tin.svagelj@live.com>
Signed-off-by: Tin Svagelj <tin.svagelj@live.com>
these are implemented on both Wayland and X11, as stubs on the former. we need
to properly dispatch these based on the backend, but for now this resolves the
conflict
This checks if a pointer offset from a heap-allocated buffer is NULL,
which is only true if the buffer is NULL and the offset is zero.
It appears to be attempting to check if an entry in an array of
pointers is zero before dereferencing that entry, but the SIOCGIFCONF
ioctl actually writes `struct ifreq` entries (not pointers to them)
into the `ifc_buf` buffer.
Furthermore, because `ifc_buf` is in a union with `struct ifreq
*ifc_req`, we can simply access `ifc_req` instead of casting `ifc_buf`
each time.
This option (store_graph_data_explicitly) can be disabled to use graphs
indirectly via execpi or lua_parse. Otherwise the graph stays empty. The
default value is true to keep avoiding resets while using conditional
colors.
I'm using the acpi_battery(4) interface, via sysctl.
It should report battery draw in mW (for milli Watts), so I'm
dividing by 1000 before printing in the buffer.
