The examples

preview	bb name	Task	What it demonstrates
	counter	—	The canonical demo. One state atom, a pure state -> hiccup view, handlers as data. The 20-line version of the whole model.
	todo	—	A task board: derived counts computed inline (glitter has no reactive-derivation primitive, the view just re-runs), an entry with :change/:activate, checkbutton toggles, list rendering in a frame.
	crud	CRUD	Live prefix filter, single-selection list box, name/surname fields, Create/Update/Delete. The spec's "separation of domain and presentation logic" is the pure get-people fn, shared by the view and the select-row expansion.
	flights	Flight Booker	Constraints between widgets and within one. The first glitter.nexus consumer, and the only demo that needs no action expansions at all: every interaction is at most two effects.
	temperature	Temperature Converter	Two linked numeric fields, each updating the other. Needs exactly one action expansion, because which field is the source depends on which one you just edited.
	timer	Timer	The first demo whose state advances on its own: a background tick via a demo-local :effect/schedule, plus a Reset button.

Every preview is a real recording of the demo running, not a mockup. They are committed under docs/demos/, and each thumbnail links to the full-size recording.

Runnable reference pages rather than tasks. Between them they use all 43 registered tags, and each is written to be copied from — widgets.md quotes them per tag.

preview	gallery
	bb gallery-inputs — every value-bearing widget, all writing into one state atom, with a readout rendering that atom, so the signal → action → effect → swap! → re-render round trip is the visible subject.
	bb gallery-layout — the containers, grouped by how each decides where a child goes: ordered lists, fixed named slots, child-driven placement, single-child wrappers.
	bb gallery-display — the read-only widgets, with no signal of their own. One :scale drives all nine, so a single value flows into nine presentations of itself.
	bb gallery-chrome — app chrome and navigation as controlled components: header/action bars, :menu-button + :popover, :notebook, :stack, :search-bar.

gallery_smoke.clj mounts all four against live GTK on every bb smokes run, so nothing quoted in the reference can quietly stop compiling.

Each one is a deliberate contrast with how the same UI would be written in glimmer, the Reagent-style sibling. counter.clj says it directly: in glimmer, local state lives in a component-scoped ratom and a click closure calls swap! itself. Here all state is in one top-level atom, the view is a pure function of it, and click handlers are data dispatched through one global fn, never closures. That difference is the whole point of the project, and it is easier to see in 20 lines of counter.clj than in any prose.

The four 7GUIs demos add a second axis: each names the specific challenge its task is designed to expose, and shows what that challenge looks like under this model. flights.clj and crud.clj are the interesting pair: same engine, and one needs no action expansions while the other's interactions can't be expressed without them.

Lenient date parsing

flights.clj needed its own parse-date. t/parse-date from jolt-lang/time is lenient, not strict: verified live that "27.03.2014x", "not-a-date" and "31.02.2014" all parse without throwing. The demo wraps it in a round-trip check (parse, reformat with the same formatter, reject unless the result matches the trimmed input), which is the only way the spec's "T is coloured red when ill-formatted" requirement actually works.

This one is structural, not a version to wait out: jolt/time/fmt.clj's parse-with-pattern is a hand-rolled field scanner, and the library has no ResolverStyle/withResolverStyle at all — DateTimeFormatterBuilder's parseLenient and parseCaseInsensitive are (fn [b] b) no-ops.

(t/today) answered the UTC date — found here, fixed upstream

flights.clj defaults its departure field to today, and opened on yesterday for the first 10 hours of every AEST day. (t/today) answered the UTC date on every machine and ignored TZ even when it was set explicitly.

Two independent jolt-lang/time defects caused it — ZoneId/systemDefault hardcoded to UTC, and the now family ignoring a zone even when handed one — and fixing either alone was not enough. Both are fixed in jolt-lang/time#10, released as v0.0.7, which is the SHA deps.edn pins. The demo calls plain (t/today).

The pin is load-bearing, and so is the toolchain: a correct local date also needs jolt v0.7.24 or newer, because zone discovery reads TZ and an older jolt leaks TZ=UTC from its own boot probe (#712). v0.7.24 also carries #716, which takes (t/today) from ~1.15ms to ~13.6us. Full write-up, including why reaching for GLib instead does not dodge any of it: nexus.md.

bb smokes runs all twenty-seven in sequence and stops at the first failure. Each is also a standalone bb <name>.

These exist because GTK4 is a live, stateful system with a blocking main loop, and several of this project's fixed bugs were "obviously correct" on paper and wrong when actually run. Each smoke pins the specific behaviour that was once broken.

Four touchpoints, and skipping any one of them leaves the example invisible to something:

1. The namespace under examples/glitter/.
2. A deps.edn alias, so jolt -M:<name> works without babashka.
3. A bb.edn task, so bb <name> works and it shows up in bb info.
4. If it's a smoke, add it to bb.edn's smokes list: otherwise bb smokes won't run it and CI-by-hand won't catch a regression in it.

A smoke must exit non-zero on failure. Do not gate it on jolt <task>: a deps.edn :tasks entry doesn't propagate its child's exit status, so jolt smoke prints failures and still exits 0. Use jolt -M:<alias> or a bb.edn task. See testing-and-tasks.md for the full rationale and CONTRIBUTING.md for the invariant list.