now that we allocate these as-needed when converting colours to the X11 representation, we need to avoid reallocating the same colour over and over; cache them so we only allocate each colour once
* 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>
these settings are used for GUI builds as well as ncurses builds, and if we support colors in console and HTTP output, will be used there too
colors really are essential to what Conky does, even if some outputs don't support them, so it makes sense to build support for them unconditionally
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.
