feat: universal element style system — resolver, schema expansion, live preview#394
feat: universal element style system — resolver, schema expansion, live preview#394ChuckBuilds wants to merge 5 commits into
Conversation
|
Warning Review limit reached
Next review available in: 5 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (11)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 531 |
| Duplication | 3 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
One shared implementation of the three things every customizable plugin re-invented: a font loader, the customization.layout x/y-offset reader, and the "did the user actually override this font?" check. The override check is the load-bearing piece: the web UI's save flow writes full schema defaults into config.json on every save, and the plugin manager merges defaults again before instantiation, so key presence never means user intent. The resolver compares against the plugin's own schema defaults (via schema_manager), degrading to caller-supplied classic defaults when unavailable. This retires the hand-maintained _CLASSIC_FONT_DEFAULTS dicts that shipped broken twice. The loader is a superset of the four per-plugin variants: alias resolution (baseball), truetype for TTF/OTF/BDF (FreeType loads BDF at native size), .pil sidecar fallback for BDF (football), fallback font, PIL default — never raises. Also introduces the text_color convention ([r,g,b], absent = keep the plugin's hardcoded color). BasePlugin gains a lazy style_resolver property (invalidated on config change) and element_style() sugar; standalone helpers receive the resolver from their owning plugin. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
…ance
Plugins can now declare styleable display elements once, compactly, on
their customization schema ("x-style-elements") instead of hand-copying
the ~50-line font/font_size/text_color/offset property blocks (currently
duplicated 52x across the plugin monorepo). SchemaManager.load_schema
expands declarations before caching, so the config form, save path,
validation, and defaults generation all see the same shape; the single
expansion implementation lives in src.element_style and is also applied
by defaults_from_schema_file, keeping the web UI's view and a plugin's
raw-schema-file view of the defaults provably identical (parity test).
Generated blocks use only widgets the config form already renders
(font-selector, color-picker, number inputs) and update x-propertyOrder
when present (the template only renders listed keys). Expansion is
idempotent, never mutates its input or the cached/on-disk schema, and a
hand-written block for the same element always wins.
Color gets the same provenance rule as fonts: the web form always posts
the RGB inputs, so a saved config carries the schema-default color
whether or not the user touched it — the resolver now only honors a
color that DIFFERS from the schema default, and keeps the plugin's
classic (possibly state-dependent, e.g. gold-on-touchdown) color
otherwise.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
Adds POST /api/v3/plugins/preview: renders a plugin headlessly with the CANDIDATE (unsaved) config and returns a PNG — so users can see exactly what the panel will show before saving, at their real panel size (from display.hardware) or a chosen test size. Two extractions make it drift-proof rather than parallel-implemented: - dev_server's _render_once moves to src/plugin_system/testing/render_service.py (pure PIL via VisualTestDisplayManager, install_deps=False always — safe in the web process, which never touches display hardware); the dev server now wraps it. - save_plugin_config's ~350-line form->config conversion is extracted verbatim as parse_plugin_config_form and shared by the preview endpoint, so preview and save can never interpret the form differently. update() is skipped by default (no network on the request thread); plugins with a test/harness.json get their mock-data fixture primed instead, and ?skip_update=0 opts into a live update. The config page gains a Live Preview panel (HTMX hx-include of the existing form, size selector, pixelated img fragment) — works for every plugin with zero per-plugin code, including the x-style-elements font/size/color fields. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
pages_v3's plugin-config partial loads config_schema.json directly from disk rather than through SchemaManager.load_schema, so declared style elements expanded everywhere EXCEPT the form the user actually sees. Found live on the devpi: the API served the expanded schema and the save path validated against it, but the config page rendered no font/color/offset fields. Apply the same (idempotent) expansion here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
Found live on the devpi: selecting a preview size did nothing because htmx snapshots the request path when it processes the button, so the size dropdown's onchange mutation of hx-post never took effect. The size now travels as a __preview_size=WxH form field attached via hx-vals (evaluated at request time); the endpoint honors it (query args still win for API callers) and strips it before form parsing so it can't leak into the candidate config. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
ChuckBuilds
force-pushed
the
feat/element-style
branch
from
d3af205 to
37c1ba9
Compare
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Summary
Stacked on #393. Universal per-element customization (font / size / color / x-y offsets) for every plugin without duplicated code, plus a live preview on the config page.
src/element_style.py—ElementStyleResolver: one shared implementation of font loading (superset of the four diverged per-plugin loaders),customization.layoutoffset reads, and the user-override check. The override check is the load-bearing piece: the save flow bakes full schema defaults into every saved config, so key presence never means user intent — the resolver compares against the plugin's ownconfig_schema.jsondefaults. This retires the hand-maintained_CLASSIC_FONT_DEFAULTSdicts that shipped broken twice.x-style-elementsschema expansion: a plugin declares a styleable element in ~6 lines;SchemaManager.load_schema(and the config-page render, anddefaults_from_schema_file) expand it into full font-selector/color-picker/offset config blocks. Idempotent, deepcopied, hand-written blocks always win. Colors follow the same provenance rule as fonts (the form always posts the RGB inputs), so untouched saves can't clobber semantic classic colors like a gold-on-touchdown score.POST /api/v3/plugins/preview+ Live Preview panel: renders the plugin headlessly (pure PIL,install_deps=False,skip_updatedefault) with the current unsaved form values, at the real panel size or a chosen test size. Reuses the exact save-path form parser (extracted verbatim asparse_plugin_config_form) so preview and save can never disagree.Verification
test_element_style.py,test_schema_style_expansion.py,test_plugin_preview.py); full suite green.hx-postpaths so the preview size selector useshx-vals.🤖 Generated with Claude Code
https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam