Today the only way to change a first-party plugin is omarchy plugin clone, which forks the whole plugin. Two small, unrelated wishes have each forced me into a clone, and each clone then has to be re-diffed against every package update.
(a) Per-plugin user overrides of icon, name and description. Something like KDE's per-widget customization: a user-level override file or shell.json entry keyed by plugin id that replaces presentation fields without touching code. My case is the network widget: the wired glyph is hardcoded in Model.js connectionIcon() (U+F0200, RJ45). I wanted U+F059F. The entire delta is one line:
if (kind === "ethernet") return "\u{f059f}" // was "\u{f0200}"That one line cost a full omarchy plugin clone of the network plugin (Model.js 371 lines, Panel.qml 1958 lines, manifest.json). The clone silently fell behind upstream (it missed the OWE / Enhanced Open changes), so I've dropped it and gone back to the RJ45 icon rather than keep maintaining a fork for one glyph.
(b) Additive extension points. Indicators.qml loads indicator blocks only from the package's indicators/ directory, with no user search path, so a user indicator cannot join the cluster (this is #8177). My delta is a single change: the loader resolves each indicator from a user indicators/ directory first and falls back to the package's on load error. The stock indicators still load from the package and track updates; only mine is local. I carry that as a patch against Indicators.qml, re-applied after every update.
A user indicators/ directory (searched after the package, or before it for override) would remove the patch. The same shape would work for other clusters and preset lists.
Both cases are a small, declarative change that currently requires carrying a fork. Related: #7355 and #7868 (clones lose first-party routing). Happy to PR either part if there's interest.
Activity
0No activity yet.