This has some other benefits too:
- No messing around with extensions and DConf settings
- The custom theme is compiled into a gresource file for efficiency
However it does cause the GNOME shell package to be compiled from scratch.
Otherwise, the default wallpaper is used for the other mode.
Ideally we would support setting two wallpapers and two colourschemes,
however that would clash with the other desktop environments which don't
have a toggle. Perhaps it's something to think about for the future?
Rather than changing the GTK theme, we now use the default Adwaita
theme with modified colours. This creates a consistent look across
all GTK3, GTK4 and Libadwaita apps.
TODO: Gnome shell theme
When using `runCommandLocal`, clients are required to download imagemagick
and the source files, even if the theme is already available from a binary
cache.
This is mainly documentation changes.
Also changed the default of `targets.grub.useImage` to a hard false,
as Plymouth doesn't use the wallpaper image any more.
This means that the OEM logo can be used to have a seamless boot process.
(Copy it in PNG format from /sys/firmware/acpi/bgrt/image)
The width of the progress bar will be adjusted to suit the width of the logo.
There is now a choice to either follow the main theme or keep a black
background.
systemd-boot enables the black background by default, as it always has a
black background itself, and keeping the same colour throughout the
whole boot process looks cleaner than applying our theme at the first
opportunity.
Making palette.json part of the system closure will protect it from
garbage collection, so future configurations can be evaluated without
having to generate the palette again. The generator is not kept, only the
palette which came from it, so this uses very little disk space.
As evaluations will no longer need the palette generator unless the
wallpaper was changed, I've removed the recommendation to add a binary
cache - the overhead of querying the cache for unrelated builds
outweighs the remaining benefits of it.
The workflow attempts to skip the deployment step when it is run on other
branches, however environment protection rules are checked before this, causing
a failure.
