Module colorpicker 

day_pieces::colorpicker is a color chooser bound two-way to a Signal<Color>, in two idioms (docs/colorpicker.md; DESIGN.md §15).

let tint = Signal::new(Color::hex(0xE86A3C));
row((
    vector(gv::nav_animation).tint(move || tint.get()).frame(28.0, 28.0),
    color_picker(tint).alpha(),              // the platform's chooser where there is one
    color_picker(tint).composed(),               // Day's own panel, identical everywhere
))

Both idioms give the app the same control, a color well: a swatch showing the current color that opens a chooser when pressed. They differ only in who draws the chooser.

• PickerIdiom::Native realizes a native leaf: NSColorWell onto the shared NSColorPanel, UIColorWell onto the iOS color picker, GtkColorDialogButton, a swatch button onto QColorDialog, the XAML ColorPicker in a button flyout, and <input type="color">. Each is the system chooser, chrome and all.
• PickerIdiom::Composed builds the whole thing out of ordinary Day pieces: a drawn swatch opening an unrouted cover that holds a canvas saturation/brightness field, a hue strip, an opacity strip and a preset palette. Every part of it is Rust that already runs everywhere, so it is the same picker on all nine targets.

PickerIdiom::Automatic, the default, is Native where the toolkit has a chooser and Composed where it does not. Two toolkits have none at any layer: Android ships no color picker in the framework, in Material, or in AndroidX, and HarmonyOS has none in ArkTS or in the ArkUI NDK. Rather than each of those growing a hand-written dialog in its own language, they get the composed panel, which is also why an app that wants one picker everywhere can just ask for it.

The value is Day’s ordinary Color, so the same signal drives .tint(…), .background(…), a canvas fill or a gradient stop with no conversion; see color guide for what that currency does and does not carry across from a native pick.

The native leaf also accepts Event::TextChanged carrying any form Color::parse reads ("#e86a3c", "#e86a3c80", "0.91 0.42 0.24 1") as a synthetic pick, so dayscript’s input: step drives it on every backend.

Structs

ColorPicker

A color well bound two-way to a Color signal. Build with color_picker.

ColorProps

Full props (realize) for the native leaf. alpha and title are set once at build; only color patches. The composed idiom realizes no leaf and never builds these.

Enums

ColorPatch

The single imperative update: show color in the well (and in the chooser, if it is open).

PickerIdiom

Which chooser a ColorPicker opens.

Constants

KIND

PICK_TAG

The tag every in-process native arm reports a pick under. Across a JNI / C-ABI / JS boundary the tag cannot be a &'static str, so it arrives empty and only the payload matters (§8.2); the front-end reads the text either way.

Traits

ColorPickerBuilder

Builder methods of ColorPicker, reachable through a Decorated (docs/api-style.md “Typed builders and erasure”): generic modifiers and typed ones chain in any order.

Functions

color_picker

color_picker(color) is a swatch showing color that opens a color chooser. color is a Signal<Color> or any other two-way binding (a day-model Field, mapped).

support

Whether the compiled backend has a native color chooser, which is what PickerIdiom::Automatic resolves against.