stores/warp-engine-client

Fork 0

Files

T

mr.zeroandClaude Opus 5 526c67b069

ci/woodpecker/manual/woodpecker Pipeline was successful

Details

Registry-only stores, a quieter window, and a CI that builds

A store no longer needs a repository of its own. The engine's built-in defaults
already cover the host-to-asset mapping, the install modes, the platforms and the
behaviour; what they cannot know is identity — a slug, a name and a catalog URL — and
that is exactly what a registry record carries. So `storeRepositoryUrl` is optional: a
record with a name and a catalog is a complete store, the id falls back from the
repository name to the catalog host (`teletypegames.org` becomes `teletypegames`) to the
display name, and the client writes a three-section config. Given a repository it still
reads it, and that file stays the authority on how the store behaves; a repository
without a config.json is treated as no repository at all.

Measured end to end against a local registry serving one record with a null repository:
the engine and the core downloaded, engine 1.1.0 accepted the written config, it listed
the same ten titles the configured store does, and a hosted title synced into a sandbox
with its menu entry written.

The "Install all" button is gone, and with it the string it used. Titles are installed
one at a time from their own cards.

No footer. The window carried a bar at the bottom at all times — a toggle and a line of
absolute paths — for something most sessions never need. The log is still there, folder
buttons included, behind a quiet switch at the bottom of the side menu; it takes no room
until it is opened, and an arriving line does not open it, because the store logs on
every refresh and a window that unfolds panels by itself is worse than one that keeps
quiet.

Three faults that every automated count had passed, found by photographing the setup
screen: the store badge rendered as an empty pill with no store open; the gate's picker
showed as an empty dropdown stub, because an explicit `display` beats the browser's own
`[hidden]` rule; and the gate went up while the empty-catalog line stayed on screen
underneath it. The last was a design fault — whether the gate is up was a call on a
view rather than state, so the two could disagree. The setup screen is now a field in
the state store, and that one field decides which of the gate and the grid is drawn.
The window test's gate assertion was wrong too: it demanded a store picker, which only
appears when the registry offers more than one store, so one store — the ordinary case —
failed it.

CI builds the packages this machine cannot. `.woodpecker.yaml` runs the checks on every
push and, on a tag or by hand, builds the Linux packages in
`electronuserland/builder:22` and the Windows ones in `:22-wine`, then attaches them to
the release with scripts/ci-upload.sh. The pipeline lives here rather than in the update
server's `/build/config` extension, which serves game-platform pipelines publishing into
the site's catalog — a different product with a different target. macOS stays a local
build: Apple's toolchain and its signing exist only on a Mac.

Both build steps verify what they produced, because a half-finished Wine build leaves a
162 KB stub named like the real installer and `ls` is happy with it. The Linux step was
rehearsed locally in the same image (AppImage 128 MB, deb 100 MB); the Wine step cannot
be rehearsed on Apple Silicon, where 16 KB host pages break Wine's 4 KB assumption, so
the runner is where it is proven. The size check was tested against both outcomes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-18 16:52:59 +02:00

4.4 KiB

Raw Blame History

WarpEngine Store 1.4.0

A store no longer needs a repository of its own. Until now every store in the registry pointed at a repository holding its config.json, and the client read that file to know what to install. It turns out almost nothing in there was necessary: the store engine's built-in defaults already cover the host-to-asset mapping, the install modes, the platforms and the behaviour. What defaults cannot know is identity — a slug, a name and a catalog URL — and that is exactly what a registry record carries.

So storeRepositoryUrl is now optional. A record with a name and a catalog URL is a complete store: the client derives the slug from the catalog host (teletypegames.org → teletypegames), writes a small config and installs. Given a repository it still reads it, and that file remains the authority on how the store behaves — which platforms it offers, which statuses it shows, where things land. A repository without a config.json is treated as no repository at all.

With the defaults, games land in a folder named after the store id and released, archived and demo titles are listed: a catalog that publishes a demo means it to be played.

The site's registry endpoint changed to match — storeRepositoryUrl answers null when there is none — and adding a store is now genuinely one database row with two fields filled in.

The "Install all" button is gone. Titles are installed one at a time from their own cards.

No footer. The window carried a bar at the bottom at all times — a toggle and a line of absolute paths — for something most sessions never need. The log is still there, with the two folder buttons in it, but it lives behind a quiet switch at the bottom of the side menu and takes no room until it is opened. The grid gets the height back.

The repository is now warp-engine-client. The app has always been called WarpEngine Store; warp-engine-desktop-gui described the role rather than the product, and the host-specific engines keep their own shape (warp-engine-desktop-store, -retroarch-store, -batocera-store). Gitea keeps a redirect from the old path, and the releases and tags moved with the repository, so existing links and clones still resolve.

Three things a screenshot found

Photographing the setup screen — which no automated count had ever looked at — turned up three faults that every check had passed:

the store badge in the bar rendered as an empty pill when no store was open;
the gate's store picker showed as an empty dropdown stub, because an explicit display in the stylesheet beats the browser's own [hidden] rule;
the gate went up while the "No installable titles in the catalog" line stayed on screen underneath it.

The last one was a design fault, not a typo: whether the gate is up was an imperative call on a view rather than state, so the gate and the grid could disagree. The setup screen is now a field in the state store, and that one field decides which of the two is drawn. The window test's gate assertion was wrong too — it demanded a store picker, which only appears when the registry offers more than one store, so a perfectly good window failed it.

Linux and Windows packages now come from CI

.woodpecker.yaml builds the AppImage, the deb, the NSIS installer and the portable exe — Windows through Wine — and on a tag attaches them to this release. macOS stays a local build, because Apple's toolchain and its signing exist only on a Mac, so a full release is one local make release plus the pipeline. The Windows installer is not signed: Windows will warn about an unknown publisher until there is a certificate.

Opening it on macOS

Ad-hoc signed, not notarised, so macOS asks first:

xattr -dr com.apple.quarantine "/Applications/WarpEngine Store.app"

What is attached

The macOS arm64 package, built and verified here, plus whatever the pipeline attaches for Linux (AppImage, deb) and Windows (installer, portable).

Verified

A repository-less store was installed end to end against a local registry serving one record with storeRepositoryUrl: null: the id came out as teletypegames, the engine and the shared core downloaded, the written config had three sections, engine 1.1.0 accepted it, it listed the same ten titles the configured store does, and a hosted title synced into a sandbox with its menu entry written. make check is clean, and the setup gate was photographed on a machine with no store at all.

4.4 KiB Raw Blame History