mr.zeroandClaude Opus 5
8511ccbef8
**The app is called WarpEngine Client.** "Store" named the thing it opens rather than the
thing you run, and the store is a catalog on a site, not a window on your machine. The
window title, the bundle, the packages and the menu entry follow; the repository already
did. The store being driven is named in the side menu, so the bar stopped repeating it as
a badge — the element stays in the page, hidden, because the window check reads it.
**Every title is listed, including the ones this machine cannot install.** They arrive
from the engine with `installable: false` and a reason, and they are drawn dimmed, with an
*unsupported platform* or *no build for this machine* badge, the engine's own sentence
underneath, and nothing to press: a disabled Install would invite a click that can never
work. They get a category of their own — *Not for this machine* — and they are kept out of
the native/hosted categories and counts, because a title with no build has no mode to be
counted under. An engine older than desktop 1.2.0 is unaffected: a missing `installable`
field reads as installable, which is what those engines mean.
**A build can be pointed at another site's registry:**
make dist STORES_API=https://games.example.org/api/stores
BuildConfiguration reads the packaged package.json, where electron-builder's
extraMetadata writes that address, so a client for somebody else's catalog needs no source
change and nothing set on the user's machine. Precedence is runtime environment, then
build, then ours — three audiences, most specific first.
Also: the scrollbars are the window's own, because the platform's light track down the
side menu of a dark window looked like a mistake.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.5 KiB
WarpEngine Client 1.5.0
The app is called WarpEngine Client. It was WarpEngine Store, which named the thing it opens rather than the thing you run — and the store is a catalog on a site, not a window on your machine. The window title, the packages, the bundle and the menu entry all say Client now; the repository already did. The store the window is driving is named in the side menu, so the bar no longer repeats it as a badge.
Every title in the catalog is listed, including the ones this machine cannot install. A C64 cartridge on a desktop, or a game with no build for your operating system, used to be silently absent — leaving you to wonder whether the catalog is small or your machine is unusual. Those cards are now there, dimmed, with an unsupported platform or no build for this machine badge and the engine's own sentence underneath, and with nothing to press. They have a category of their own, Not for this machine, and they stay out of the native/hosted counts: a title with no build has no mode to be counted under.
This needs store engine 1.2.0 (desktop) on warpstore 1.4.0, which report what they had to leave out and why. An older engine still works — its listing is simply all installable, as it was before.
A build can be pointed at another site's registry.
make dist STORES_API=https://games.example.org/api/stores
The address is written into the packaged app's own package.json, so a client built for
somebody else's catalog needs no source change and nothing set on the user's machine. A
runtime STORES_API still wins, which is for trying something out rather than shipping.
Also
The scrollbars are the window's own now: the platform's light track down the side menu of a dark window looked like a mistake.
Opening it on macOS
Ad-hoc signed, not notarised, so macOS asks first:
xattr -dr com.apple.quarantine "/Applications/WarpEngine Client.app"
What is attached
The macOS package, built and verified on a Mac, plus the Linux (AppImage, deb) and Windows (installer, portable) packages the pipeline builds when the tag is pushed.
Verified
make check is clean. The store on this machine lists 13 titles — ten installable, three
C64 cartridges this store does not carry — and the window was photographed with all
thirteen on screen, the three dimmed and labelled. The engine change was measured through
the CLI as well, in both its human and its --json listing, and the other two store
engines still get the two-value answer they ask for.