• v1.2.0 cd5361e222

    mr.zero released this 2026-08-18 12:13:31 +00:00 | 16 commits to master since this release

    WarpEngine Store 1.2.0

    A side menu. Everything that is not a title moved out of the bar into a menu on
    the left that folds away with : the stores on this machine, the two actions, the
    categories and the language. Open or closed is remembered between runs.

    Categories. The grid narrows to Installed, Updates or Not installed, to a
    platform (godot, tic80, love, …), or to native/hosted titles — one at a time,
    each with its count. The axes are built from what the catalog actually contains, so
    nothing empty is listed, and a category that disappears under you falls back to
    Everything rather than leaving a blank grid.

    Switching stores. With more than one store installed, clicking another in the
    menu opens it: the grid, the categories and the folders follow, and the client
    reopens on the store last used. Two stores installed from the same catalog into
    different folders are told apart by their folder, since their id is identical.

    While the store is working, the menu, the log drawer and the filters keep working —
    only what would start a second call is disabled.

    The grid was broken, and now is not. Its rows split the window's height evenly
    rather than following their content, so every card came out 94px tall: the box art
    collapsed to nothing and the action buttons were clipped away below the fold. The
    DOM was intact the whole time — ten cards, twenty buttons — which is why every
    automated count passed. Cards now carry a band of art of one height, with the
    title's first letter where the catalog has no image.

    Unchanged from 1.1.0: which stores exist is the site's answer (GET /api/stores),
    not something baked into this app, and STORES_API overrides that address.

    Opening it on macOS

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

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

    Open Anyway under System Settings ▸ Privacy & Security works as well.
    Nothing the store itself downloads is affected — Python fetches those, and Python
    does not set the quarantine flag.

    What is attached

    macOS arm64 only, the machine this was built and verified on. Windows and
    Linux packages need a build on those platforms (make dist-win / dist-linux).

    Verified

    SELFTEST_SHOT=shot.png npm run uitest has the window photograph itself, which is
    how the collapsed rows were found and how the fix was confirmed — in English and in
    Hungarian, with the menu open and closed.

    npm run uitest loads the window and reports what rendered; with two stores in one
    root — a sandbox copy beside the real install — it now also clicks the store that
    is not open and checks that the bar, the grid and the categories follow. Both runs
    pass, and npm run smoke drives the same bridge with no window at all: ten titles,
    five native and five hosted, every installed one with something to launch.

    Downloads
  • v1.1.0 0f5da38a27

    mr.zero released this 2026-08-18 11:26:31 +00:00 | 17 commits to master since this release

    The client no longer carries a store address. It asks the site which stores exist
    GET /api/stores — and installs what comes back: one record and there is
    nothing to decide, several and the setup screen shows a picker.

    Adding a store is now a database row on the site, maintained from its admin panel,
    rather than a release of this app.

    What a record gives it

    • storeRepositoryUrl → the store's config.json, which stays the authority
      on how that store behaves: platforms, statuses, where things land.
    • catalogUrl and name override the config's store.base_url and
      store.name — the registry is what says which catalog a store is for.
    • the store id, from the repository name: ttg-desktop-store becomes ttg.

    A store repository with no config.json still installs. The engine merges
    whatever it is handed onto its own defaults, so the client writes a three-field
    config and the store behaves like the default one pointed at that catalog.

    STORES_API overrides the registry address, which is the one thing about a
    particular site left in the client.

    Opening it on macOS

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

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

    Open Anyway under System Settings ▸ Privacy & Security works as well.
    Nothing the store itself downloads is affected — Python fetches those, and Python
    does not set the quarantine flag.

    What is attached

    macOS arm64 only, the machine this was built and verified on. Windows and
    Linux packages need a build on those platforms (make dist-win / dist-linux).

    Verified

    Against a local endpoint serving the same payload the site returns, with two
    records — one store whose repository has a config.json and one without. Both
    installed, and the engine listed all ten titles with the synthesised config. The
    window was checked on both outcomes: the grid with a store present, the setup gate
    with a populated picker when there is none.

    Downloads
  • v1.0.1 f88340d63c

    mr.zero released this 2026-08-18 09:42:58 +00:00 | 21 commits to master since this release

    Fixes a macOS packaging fault: v1.0.0 would not open at all, reporting
    "WarpEngine Store is damaged and can't be opened."

    Open it on macOS

    The app is ad-hoc signed but not notarised, so macOS asks before running it.
    The reliable way through, once it is in your Applications folder:

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

    If macOS offers Open Anyway under System Settings ▸ Privacy & Security after
    a blocked attempt, that works too. Nothing the store itself downloads is affected:
    Python fetches those files, and Python does not set the quarantine flag.

    Notarisation is the only way to remove this step, and it needs a paid Apple
    Developer ID.

    What was wrong

    v1.0.0's bundle carried only the linker's ad-hoc signature on the main
    executable, with no resource seal — codesign --verify said "code has no
    resources but signature indicates they must be present"
    . That is an integrity
    failure, and macOS reports it as damaged rather than merely unverified, with no
    way to approve it.

    The build now signs the bundle itself (scripts/after-pack.js), and the result
    verifies: valid on disk, satisfies its Designated Requirement, with our own
    bundle identifier rather than Electron.

    Measured before and after, on the artifact from this release:

    v1.0.0 v1.0.1
    codesign --verify --deep --strict no resource seal valid on disk
    launches without quarantine yes yes, self-test passes
    launches with quarantine reported as damaged still needs the approval above

    What is attached

    macOS arm64 only — the machine this was built and verified on. Windows and
    Linux packages need a build on those platforms (npm run dist:win / dist:linux)
    and are not attached.

    Downloads
  • v1.0.0 f88340d63c

    mr.zero released this 2026-08-18 08:55:52 +00:00 | 21 commits to master since this release

    The packages are withdrawn: they could not be opened. macOS reported "WarpEngine Store is damaged and can't be opened" — the bundle was never signed, only its main executable carried the linker's ad-hoc signature, so the resource seal was missing and Gatekeeper refused it outright.

    Use v1.0.1, which signs the bundle in the build. The attachments here have been removed so nobody downloads an app that cannot start.

    Downloads