xpui-gallery

Ten captures on seven boards, and the suite that proves the framework paints the same thing on all of them. Run it and you have a window showing every widget xpui has, on whichever device you name. The same screens are what the two firmwares flash: they have been run on a Badger and a Tufty, and they build for an X3 and a Sticky, which have no panel driver yet.

Which crate you want

gallery	The reference application, and a library both firmwares depend on. Its tests/ are the seven-board conformance suite: ten captures × seven panels — eight screens, one of them in two states, plus a picker — for 70 golden images, and three more for typefaces. Then row overflow, chrome-for-a-board and the headless simulator loop
tutorial	The screen the framework's tutorial builds, compiled and snapshotted — so the page a beginner follows cannot drift from an API that moved

gallery is not an example. Two firmwares link it, and it is where a board and a backend actually meet — which is why the tests that need both live here rather than in either.

Using it

cargo run -p xpui-gallery -- --board x3     # and x4, x4pro, sticky,
                                            # badger2040, tufty2040, inkyframe

A firmware takes the screens as a library:

[dependencies]
xpui-gallery = { git = "https://github.com/XPUI-Framework/xpui-gallery", branch = "main" }

It depends on everything below it — xpui, xpui-chrome, xpui-boards, xpui-backends and xpui-simulator — because it is the caller, the one repository that names them all; and xpui-rp2040 and xpui-esp32 each flash these screens onto one device. Nothing is on crates.io yet, which is what the banner above is about.

Requirements

SDL2, which the simulator links: brew install sdl2 on macOS, apt install libsdl2-dev on Debian and Ubuntu. The tests run headless and need no display.

Checking it

./build-and-test.sh

The checks themselves are in xtask/ — this repository's own list, in Rust, holding nothing it does not run. ./build-and-test.sh fix formats in place first. A first run of a new golden writes it and fails, so nobody commits a picture they never looked at; docs/conformance.md is how to read a failure and re-bless, and docs/contributing.md is how a change is reviewed.

Where next

docs/conformance.md	the seven-board suite: what it captures, how to run it, what a diff looks like, and how to re-bless
docs/design.md	why the suite is here, why the gallery is a library, the double press, the cost of two typefaces
docs/contributing.md	SDL2, every board every time, the gate, the five review steps, and how a commit is written

Where it sits

Every arrow is a dependency in a Cargo.toml, and they all point inward toward xpui, which depends on nothing at all. That is the rule the organisation is arranged around: a backend can be written without the framework knowing it exists, and a firmware reaches whatever it needs directly rather than through whoever happens to sit above it.