Detect the terminal background (via COLORFGBG or an OSC 11 query) before
GUI init and, on the first start, automatically apply the built-in
"light" theme when a light terminal is detected.
The function gui_term_theme_is_light returns an int (1 if light, 0 otherwise,
0 being the safe value when detection is unsure).
Introduce a new module (core-theme.{c,h}) holding the in-memory registry
of built-in themes used by the upcoming /theme command:
- struct t_theme stores name, description, date and weechat version
captured at registration time, plus a hashtable of overrides keyed by
full option name (file.section.option) -> value string.
- theme_register (name, overrides) creates a new theme or merges the
given overrides into an existing one (later calls override duplicate
keys); this is the API plugins and scripts will use to contribute
per-theme color values.
- theme_search and theme_list provide lookup and ordered enumeration.
- theme_init / theme_end are called from weechat_init / weechat_end.
The theme_applying flag is declared here but not yet consumed (it will
gate config_change_color in the next commit to avoid N redundant
window refreshes during /theme apply).
User theme files are not handled by this module: they are read
transiently inside /theme apply (a later commit) and never cached.
Move the requirement checking and the dummy test where they are used.
Use REQUIRED instead of the manual FOUND check and error handling.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
With CMP0083 introduced with cmake 3.14, as we set the variable
CMAKE_POSITION_INDEPENDENT_CODE we can rely on the build system to do
the correct thing, across all the targets.
Since we require 3.18 (or 3.16 in the patched Debian/Ubuntu version),
which sets the policy to NEW we're all set.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Note that final handling varies a bit, namely:
- OpenBSD/intl should be handled via the existing cmake/FindGettext.cmake
- Darwin/resolv should not be needed since commit e98a32373 ("core: check
if res_init requires linking with libresolv")
- the backtrace/execinfo handling has been consolidated and moved
In the unlikely case of unwanted over-linking, the platforms can add
`-Wl,--as-needed` to their linker flags. Something which is strongly
encouraged and has been the default across multiple (linux) distros for
years.
Alternatively, if move quirks are needed they should be handled in a
single place.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Move the handling to the top-level, adding it _once_ to EXTRA_LIBS.
Thus avoiding some duplication across the board.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
In a handful of places we explicitly use add_dependencies() where the
exact same libraries are also (implicitly) added as dependencies via
target_link_libraries().
Remove the folder, which helps us remove some duplication with follow-up
patches.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Sébastien Helleu