* specials: comment all parser cases
* specials: scan_graph: early-return if args is null
* specials: fix logic in scan_graph
* tests: add scan_graph parsing test
* specials: separate command parsing from graph parsing
this simplifies the implementation of graph parsing and makes it less ambiguous to parse graphs in contexts where commands are not expected
* specials: tweak comments in scan_graph
* tests: update for scan_command separation
---------
Co-authored-by: bi4k8 <bi4k8@github>
* gradient, colours: use 24-bit colour depth internally on Wayland
our Colour type assumes this anyway; lower colour depth should be handled by display backends
* core: restore gradient color computation
this was mistakenly disabled when moving to a unified Colour representation
* core, gradient: use Colour type
* tests: gradient: always test hsv/hcl
colour computations no longer depend on the display backends we compile with, so these can be tested unconditionally now
* gradients, specials: use Color type
this makes specials now accept color names as well as hex codes, and removes all notions of color depth from gradient calculations
---------
Co-authored-by: bi4k8 <bi4k8@github>
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.
Retrieve graph only when s->graph is already allocated, which also mens
that the s->graph_width is bigger than 0, and thus avoid out-of-bounds
write in graph_append function.
Prior to 594d0c85ba ("Fix bug of "Graph reset when using conditional
color"") s->graph was not (re)allocated when s->graph_width and
s->graph_allocated were equal to zero, therefore, s->graph stayed equal
to nullptr. This effectively meant that graph_append function returned
immediately after call and did nothing.
This behavior changed with introduction of std::map<int, double *> graphs,
because its retrieve_graph support function allocates s->graph even for
s->graph_width equal to 0. Then, subsequent call of graph_append can
continue and the first element of the graph is set later in this
function in line:
graph->graph[0] = f; /* add new data */
causing out-of-bounds write, as there is not enough space in array of
zero length. This write messes up internal data of memory allocator (at
least in musl libc case) and the application later segfaults in attempt
to free this memory in store_graph function.
Fixes: 594d0c85ba ("Fix bug of "Graph reset when using conditional color"")
Graphs would appear to change their previous data when any of the
displayed special types (e.g. $color, $hr, $offset) was added or removed
from the display (e.g. from a conditional statement). This is because
Graphs were just looking at memory locations for previous graph data,
but those locations could change if any special types were added or
removed. Now the previous graph data will get stored explicitly.
* Fix race condition in gw_info handling.
* Fix a couple potential nullptr derefs.
* Fix font handling without x.
* Fix regression in output to ncurses with X disabled.
* Apply some formatting/code smell fixes.
The code was multiplying the index with the size of the element, and
then adding it to the typed pointer (resulting in a double
multiplication and an OOB access).
Replace the buggy code with a slightly safer c++ alternative.
When parsing the argument string for graph objects, check if there is a
double-quoted command in the beginning of the string and extract it
before parsing any options. This prevents items in a command from being
improperly recognized as graph options. It should also eliminate the
need to place commands with spaces into a separate script.
Also, fall back on default_graph_{height,width} instead of using
hard-coded values so that the default values set in a user's config will
work.
e.g. in the beginning the scale is always 0, leading to NaN and a crash
fixes the "show_graph_scale" not working bug, not yet reported (even though I actually noticed that before, didn't seem to bother me)
also cpugauge works again because fo this BUILD_MATH MATH problem
apparently, this was actually a feature as someone made it deliberately act that way. However, I
agree with the bug reporter that it is strange so I remove it.
