* display-x11: fix memory leaks
FcFini() was never being called, which meant FontConfig did not clean up its internal storage.
furthermore, restore a commented-out call to XftFontClose()
9acf0bb4c commented this call out, but it does not seem to cause any problems now on reload now
* feat: Move docs to website, rearrange bits (#1475)
* build(deps): bump actions/stale from 7 to 8 (#1472)
Bumps [actions/stale](https://github.com/actions/stale) from 7 to 8.
- [Release notes](https://github.com/actions/stale/releases)
- [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/stale/compare/v7...v8)
---
updated-dependencies:
- dependency-name: actions/stale
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* Add fontconfig platform checks
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: bi4k8 <bi4k8@github>
Co-authored-by: Brenden Matthews <brenden@brndn.io>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Brenden Matthews <github@brenden.brndn.io>
* specials: avoid duplicating color specials when both ncurses and a graphical output are enabled
* ncurses: fix black
we previously used the ncurses color as the id for its color pair, but this scheme needs to be shifted by one to avoid using the invalid 0 color-pair id for black (color id 0)
---------
Co-authored-by: bi4k8 <bi4k8@github>
* gradients: fix saturation calculation for 32-bit systems
this multiplication has two 512 scale factors as well as 360 and a color difference of up to 255. as such, it can overflow 32 bits, which results in an incorrect saturation value being computed
cast to uint64_t so we have enough bits to multiply without overflow
* gradients: fix luma calculation for 32-bit systems
this multiplication has 0-255 colors at 512 scale factor being multiplied by 10000 (summed across components), then multiplied by 360
this multiplication (360 * 10000 * 255 * 512) overflows a long on 32-bit systems, computing the wrong luma value
cast to uint64_t so we have enough bits to multiply without overflow
---------
Co-authored-by: bi4k8 <bi4k8@github>
* 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>
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
* initialize XColor/XftColor
this does not change behavior, but avoids passing uninitialized data to X/Xft functions
* gui, x11: move have_argb_visual to x11 files
this variable only has meaning with respect to X11
* x11: clear have_argb_visual if the setting changes to false
otherwise, we may try to use colors with alpha when we no longer requested a 32-bit visual
* x11: premultiply alpha of background colors
* x11: clean up set_foreground_color a bit
---------
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>
* Add libXdamage to flake.nix
* Add TYPE_UTILITY as above-all alternative to TYPE_OVERRIDE
* Click-through for TYPE_UTILITY
* Added libxfixes to MacOS CI workflow
* Disable building of XFIXES on MacOS
* Fix build for xinerama/xfixes on macos.
* Update Lua version check.
* Tidy this up.
* Fix BUILD_XFIXES on Linux
* Sigh, fix this.
---------
Co-authored-by: tranquillity-codes <dev@itycodes.org>
Co-authored-by: Brenden Matthews <brenden@brndn.io>
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.
* 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.
