feat(football-scoreboard): opt-in adaptive layout + core element-style resolver (v2.8.2)#186
feat(football-scoreboard): opt-in adaptive layout + core element-style resolver (v2.8.2)#186ChuckBuilds wants to merge 7 commits into
Conversation
Point authors at the adaptive layout system, the dev server's All Sizes gallery, the harness fill-check warnings, and the manifest design_size / strict fill_check opt-ins. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add layout_mode: "classic" | "adaptive" (default classic — rendering is byte-identical to 2.7.0 unless the user opts in; the celebration goldens prove the classic path in CI). Adaptive mode renders game cards via the core adaptive layout system: scoreboard_regions() replaces the magic y=1 / y=H-7 / H//2-3 coordinates, fonts ladder-fit per region (32px score on a 256x128 vs the fixed 10px), and logos fit via crop-to-ink fill-height with size-keyed caching. User customization is preserved in adaptive mode: explicitly configured customization.<element>.font/font_size win over the ladder, and customization.layout.<element> x/y offsets translate the computed regions as a final step (adaptive also honors these offsets in scroll mode, which classic scroll never did — noted in the changelog). Semantic colors (redzone red, touchdown gold) pass through unchanged. Switch mode (live/recent/upcoming) delegates to the shared GameRenderer when adaptive, so switch + scroll + celebration share one adaptive implementation; older cores without src.adaptive_layout silently keep the classic layout. Manifest declares display.design_size 128x32. Revert path: set layout_mode back to "classic" in config (no reinstall), roll back to 2.7.0 in the store, or git-revert this single commit. Tests: test_adaptive_layout_mode.py — classic-unchanged byte-identity, ladder scale-up, user font/offset precedence, semantic colors, and adaptive goldens at 128x32/128x64/256x128 in test/golden-adaptive/. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…daptive mode (v2.8.1) Two bugs found while reviewing real renders of the beta adaptive layout: 1. Blurry text: ADAPTIVE_LADDER_HEADLINE included press_start@10px/12px (not multiples of PressStart2P's 8px design grid -- 18-30% antialiased) and ADAPTIVE_LADDER_TEXT fell back to '5by7.regular'@8px (antialiased at every size tested) with '4x6-font' at 6px instead of its actual crisp 7px. All fixed; both ladders now only contain rungs verified at 0% antialiasing (measure_font_crispness, new TestLadderCrispness). 2. Score overlapping logos on large panels: _fit_element always picked the largest crisp font that fit its own region. On a big panel the score's region has generous room while the logos scale by a fixed geometry factor (px()) -- maximizing let the score balloon large enough to visually collide with the logos next to it (most visible on 96x48 and other squarish/tall panels where the text bands span the full card width). Switched to the new core fit_text_proportional(): target size = classic's fixed size (score=10/status=8/detail=6) times the panel's scale factor, capped at the largest rung that still fits. 256x128 score is now 16px (proportional) instead of 32px (maximized) -- still 3.2x classic's fixed 10px, still crisp, no longer overlapping. Regenerated test/golden-adaptive/ to match; test_adaptive_text_scales_up_on_big_panels updated to assert the new deterministic proportional value. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… logos _fit_element's proportional target used LayoutContext's default self.scale (min of width_ratio, height_ratio) — conservative and correct for content whose aspect ratio matters, but the card's own logo_slot already scales by height alone (min(height, width // 2)). On a panel that only grows taller (128x32 -> 128x64), self.scale stays 1.0 since width didn't grow, so score/status/detail text barely grew while the logos next to it doubled -- text read as under-scaled relative to the rest of the card. Uses the new core fit_text_proportional(..., scale=height/design_height) override so text tracks the same axis the logos do. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…er-reserve fix No plugin code changed here -- game_renderer.py is untouched. The fix lives entirely in LEDMatrix core's scoreboard_regions() (logo slots now reserve real center space at 2:1-and-tighter aspect ratios, where they previously claimed the full card width and left the score with nowhere to render but on top of the logos). Any football-scoreboard install picks this up automatically on a core update, with no version bump needed here. test_adaptive_layout_mode.py gains direct coverage: center_col is never zero-width at 2:1 aspect, and the score never needs ellipsis. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… config Same bug class as ledmatrix-music's identical fix: _user_font_set() treated the mere PRESENCE of customization.<element>.font or .font_size as 'the user explicitly forced this font' and skipped adaptive sizing. But the web UI's save flow (schema_manager.merge_with_defaults, api_v3.py save_plugin_config) writes the FULL schema-declared default object into config.json on every save -- for every plugin, whether or not the user touched that section. config_schema.json declares a font/ font_size default for every element (score_text, period_text, team_name, status_text, detail_text, rank_text), so ANY config that has ever been saved once via the web UI already has these keys present -- meaning _user_font_set() returned True unconditionally, and adaptive font sizing never actually engaged in practice. Fixed by comparing the configured (font, font_size) against the classic default for that element (the same defaults _load_fonts() already passes to _load_custom_font), not just checking presence. Existing golden tests were unaffected because the test harness never populated a customization block in the first place -- exactly the blind spot this bug exploited in real deployments, where the web UI always does. test_user_font_wins_over_ladder updated to use a font_size that genuinely differs from default (14px vs the 10px default, was 10px which is now correctly NOT an override); new test_schema_default_is_not_mistaken_for_a_user_override covers all six font elements. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Delegate font loading, layout offsets, and the user-font-override check to src.element_style (new core module) instead of the plugin-local copies. The resolver reads its override reference from this plugin's own config_schema.json, so "schema default present in a saved config" is never mistaken for a user override — in every context, including the test harness and dev server where no schema manager exists. Behavior-identical: verified byte-identical renders old-vs-new across 5 configs (bare/realistic x classic/adaptive + a real override), 5 panel sizes, and 3 game states (75 comparisons), plus the full safety harness. The local loader and defaults tables remain as the fallback path on older cores without src.element_style. One deliberate improvement on the resolver path: a user-selected BDF font is now actually loaded (FreeType handles BDF at its native size); the old loader silently substituted PressStart2P. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam
|
Warning Review limit reached
Next review available in: 59 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 ignored due to path filters (9)
📒 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 | 118 |
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.
|
@coderabbitai review |
✅ Action performedReview finished.
|
Summary
Verification
🤖 Generated with Claude Code
https://claude.ai/code/session_01FqzC1nzTWL4kaqgMaQZFam