Skip to content

Added Theme Termius Dark - #4

Open
Auhrus wants to merge 1 commit into
VoltiusApp:mainfrom
Auhrus:main
Open

Added Theme Termius Dark#4
Auhrus wants to merge 1 commit into
VoltiusApp:mainfrom
Auhrus:main

Conversation

@Auhrus

@Auhrus Auhrus commented Jul 29, 2026

Copy link
Copy Markdown

I built a theme similar to Termius because I really like the Termius design.🙂
I hope the hash works out.

Added the Termius Dark Theme
@kipavy

kipavy commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Thanks — hash stamped and no runtime deps is the right shape. Four things before I can merge.

1. Name

I can't ship a theme named after another product in the official marketplace. The palette itself is fine and clearly your own work.

To be precise about where the line sits, since Voltius itself ships plugins called "Docker" and "Proxmox LXC": naming a plugin after the thing it integrates with is fine — it describes function and implies no affiliation. Naming one after another product it resembles is not, because the name implies endorsement and reads as deliberate imitation. A theme is the second case.

Pick any name that isn't another product's — entirely your call. Rename before merge, not after: the theme id is the key a user's theme selection is persisted under, so a later change silently resets everyone who picked it.

Occurrences:

  • PR title
  • plugins.jsonid, name, description
  • termius-dark/ directory
  • manifest.jsonid, name, description
  • package.jsonname
  • src/index.ts → theme id, name
  • index.js → same two

2. Two typos

gCardHover: "#2d73e040"   → bgCardHover
orderHover: "#ffffff00"   → borderHover

As written, --t-bg-card-hover and --t-border-hover are never set and inherit whatever the previously-active theme left on :root — so card-hover and border-hover render differently depending on which theme the user switched from. Present in both src/index.ts and index.js.

3. Rebuild, don't hand-patch index.js

index.js is built output — fix src/index.ts and regenerate, or the two drift. Your build script emits to dist/index.js, which is gitignored; copy it to the plugin root as the committed index.js.

4. Hash mismatch

declared: ff9f94e48ffb1d95b1e17298c636c15db483de8cad87158c6fac61a27c412539
actual:   a8a867385f0860f5fac0dad2677c80084990999518ae69b83824abb5fdf8e64b

The client refuses to execute a bundle whose bytes don't match, so this won't install as-is. After rebuilding:

node scripts/stamp-hashes.mjs

Needs re-running after the rename and the typo fix anyway. CI now shows this too — I've approved the workflow, so the hash check runs on your next push.

If you'd rather keep the name

Then it just can't be in the official marketplace. Voltius takes any plugins.json URL as an extra source (Settings → Plugins → Browse → Add source), so you can publish your fork under any name and share the URL.

Caveat on the current release: added sources aren't persisted across restart, and update detection only sees currently-loaded sources — so a v1.1 would never reach v1.0 installs. Both are already fixed on dev and ship in the next release. Merging here sidesteps it entirely, which is why I'd prefer it, but the choice is yours.

@kipavy

kipavy commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Regarding 3rd party plugins repos, an update is coming soon to improve their support

@kipavy

kipavy commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

One addition, since the catalogue schema changed after my last comment.

Entries now carry a permissions array, stamped from the plugin's own manifest.json and verified by CI alongside the hash. It makes what a plugin requests visible in the PR diff rather than only in its manifest. For this theme it's ["themes"].

Nothing extra to do — node scripts/stamp-hashes.mjs writes both fields, and you were already re-running it for the hash. Just don't hand-edit the entry: if permissions is missing or disagrees with your manifest.json, verify now fails the same way a wrong hash does.

The rest of my previous comment stands unchanged.

kipavy added a commit that referenced this pull request Aug 1, 2026
…licy (#7)

The catalogue carries third-party submissions and all six first-party plugins, but
no written criteria covered the permission tiers 0.14.0 shipped, and the naming rule
ruled on in #4 was never written down anywhere a contributor could read it.

CONTRIBUTING gains a Naming section (no third-party trademarks, with the nominative
carve-out for what a plugin integrates with), a Permissions section documenting the
three tiers and the two listing requirements, and a reviewer checklist that doubles
as a submitter self-check.

Any plugin may request any permission — the gate is manifest declaration plus
install-time consent, not provenance — so there are no outright denials. What is
required is that declared permissions be justified by the described functionality,
and that anything declaring a gated permission publish readable source.

Entries now carry `permissions`, stamped from the served manifest.json and verified
by --check, so a submission's requested capabilities are visible in the PR diff
rather than only in a release asset. The workflow's paths filter gains manifest.json:
without it an in-repo plugin's declared permissions could change without verify
running at all.

Closes #2
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