The seed in use, for a picker that wants to open on the current color.
What a given seed would look like, without applying it.
The swatch a preset button renders is the wallpaper that preset produces, generated the same way — so the button cannot advertise one thing and set another, which is exactly what a hand-written gradient beside a hand-written seed allowed.
Use a photo, optionally re-seeding the theme from its dominant color.
The seed is separate because a photo does not have to dictate the accent — and
seedFromImage returns null when it cannot read one, in which case the picture
changes and the colors stay put.
Pick a color: the wallpaper and every role in the phone follow it together.
The CSS background for whatever is currently set.
One value, one format, whichever kind of wallpaper it is — so PhoneFrame writes it to
one property and never chooses between a class and a style.
Whether text drawn over the wallpaper needs the .text-on-wallpaper treatment.
The one preference that stays on this PC.
Every other setting follows the player's citizenid to any machine. This one cannot affordably: a custom wallpaper is a base64 data URL of unbounded size, and syncing it would push megabytes across the NUI bridge and into MySQL every time the color changed.
The part players actually notice does still follow them — the seed and light/dark mode
live in themeStore, which syncs, and they are what generate the whole scheme. What
stays behind is a photo you set from this machine's own gallery.
The phone's home screen background.
A background is a color or a picture, and a color is the theme seed — the gradient is generated from the scheme that seed produces, so a preset and a color dragged off a wheel travel the identical path. There is nothing to keep in sync because there is only one input.
seedFromImageis how a photo becomes a theme: it quantizes the image and returns its dominant color, ornullif it cannot (a non-data:source, a failed decode).nullmeans keep the current seed, not "use black".