Skip to content

bundle Decal, the open-source ReaPrime skin - #798

Open
ChampionDesigns wants to merge 1 commit into
decentespresso:mainfrom
ChampionDesigns:ben/bundle-decal
Open

bundle Decal, the open-source ReaPrime skin#798
ChampionDesigns wants to merge 1 commit into
decentespresso:mainfrom
ChampionDesigns:ben/bundle-decal

Conversation

@ChampionDesigns

Copy link
Copy Markdown
Collaborator

Summary

Lists Decal in skin_sources.json, so Decaid bundles it the way it already bundles six other
third-party skins.

Base: main. Independent. Four lines.

{
  "type": "github_release",
  "repo": "ChampionDesigns/decal"
}

What this is and is not

assets/bundled_skins/ is gitignored — Decaid does not commit skins. It reads this manifest and
fetches each repo's latest release. So this PR adds no skin code, only a source to fetch from,
exactly as allofmeng/streamline_project, tadelv/passione, rotium/OverDose,
giladger/Beanie, NilsBruch/NSX and Sabotage1/WorkFlow-Skin already are.

Whether Decaid should ship Decal is a product decision, not a technical one. The change itself
is trivial; the question is whether you want it in the box.

Linked Issue

N/A

Verification

  • flutter analyze — clean.
  • flutter testfull suite 3891 passed / 1 skipped, run against current main on
    5 Sep 2026.
  • flutter testtest/webui_support 26 passed.
  • skin_sources.json parses; 8 entries, Decal among them.
  • ChampionDesigns/decal is public and has release v0.1.0 with decal-0.1.0.zip, matching
    the single-zip asset shape the fetcher already consumes from passione-v0.9.5.zip.
  • Verified on hardware. Decal is bundled in the Decaid-Canary build Ben runs, fetched from the
    same public release this entry points at.

Impact

  • User-visible: Decal appears in the bundled skin list on a fresh install.
  • Download size: one more skin fetched at first run — decal-0.1.0.zip is about 1.0 MB.
  • Compatibility: additive. Existing installs are unaffected until they refresh their skin list.
  • Security: the skin is fetched from a public GitHub release, the same trust path as the other
    six.

Contributor Responsibility

AI-assisted development is allowed. The submitter remains responsible for the submitted work.

  • I have reviewed and understand all changes in this PR and take responsibility for their correctness, security, behavior, licensing, and provenance, including any AI-assisted or AI-generated work.

One source, which does two jobs from one file. `bundle_skins.sh` reads it at BUILD
time and downloads the release zip into assets/bundled_skins/, so the skin is
present on a machine with no network; the app reads the same file at RUN time in
downloadRemoteSkins(), so it is re-fetched on the twelve-hour update pass.

The repo is named `decal` deliberately. bundle_skins.sh names the bundled file
after the REPO (SKIN_ID="$REPO_NAME") and the app then checks web-ui/<that name>
before installing. `decal` is also the skin's own manifest id, so the check looks
where the skin actually lands. Any other repo name and the app would re-extract the
skin on every launch, because it would be looking for a directory that never exists.

Verified by running the bundler: 8 of 8 sources bundled, decal.zip is 1023 KB, and
the manifest inside it reads id `decal`, version 0.1.0.

Canary-only. The choice to ship this skin is ours; if it should go to stock Decaid
it wants a lane cut from upstream/main and Vid's agreement, not this one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tadelv commented Sep 8, 2026

Copy link
Copy Markdown
Member

Thanks. I don't want to add new bundled skins to Decaid at the moment. Our highest development priority is the generic device-driver/plugin infrastructure, and until that work settles I'm keeping new skin and plugin bundling out of the core distribution.

Decaid already has a native installation path for third-party skins:

Launcher → Skins → + → GitHub Release

From there a user can enter ChampionDesigns/decal and install/update Decal without it being added to Decaid's bundled skin sources.

I think the best way forward is therefore to document that installation path in the Decal README rather than bundle Decal in Decaid. The current README still points users at the raw /api/v1/webui/skins/install/url API; replacing that with the native UI instructions would make Decal straightforward to install without requiring any Decaid change.

I'm leaving this PR open for now, but I don't plan to merge skin-bundling changes while the generic-driver work remains the priority.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants