fix(vegas): stop capping plugin width by default - #445
Conversation
Vegas plugins read as "cut off early" or "starting in the middle". That was the per-plugin width budget, not the scroll engine: overflow_mode=rotate is designed to resume mid-content on each appearance, so the symptom was the feature working as specified. Measured over a 17-plugin fleet on a 512px panel, the cap was a bad trade. Only four plugins were ever wide enough to hit the 3.0 default -- leaderboard 11,518px, news 10,021px, odds-ticker 4,643px, hockey 1,508px. Weather is 650px and flights 512px; the cap never touched them or the other eleven. So it bought nothing on thirteen plugins while costing two visible faults on four: content entering mid-item (a news ticker started at column 6027 of its own strip), and a final rotation window of whatever happened to be left -- 348px of an 1,840px stocks ticker, seven seconds of panel time. Default max_plugin_width_ratio to 0 (uncapped), so every plugin contributes all of its content and is always entered at its beginning. The cap remains available, and vegas_max_width_screens still caps an individual plugin -- which is where the knob belongs, since a genuinely long ticker is a property of that plugin rather than of the fleet. Verified on a live 512px device: 327 budget crops in the preceding six hours, none after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
|
Warning Review limit reached
Next review available in: 55 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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 Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe default ChangesPlugin width default
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 | 0 |
| Duplication | 0 |
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[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
test/test_vegas_density.py (1)
784-789: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCover the preserved opt-in path.
The test checks only omitted values. Add a case with an explicit
3.0value. This protects the contract that the width cap remains available after the default changes.Suggested regression case
def test_width_cap_is_off_by_default(self): # Capping made wide plugins resume mid-content on every appearance and # emit runt final windows; it is now opt-in per plugin instead. assert VegasModeConfig().max_plugin_width_ratio == 0.0 assert VegasModeConfig.from_config({}).max_plugin_width_ratio == 0.0 + + def test_width_cap_can_be_enabled(self): + cfg = VegasModeConfig.from_config({ + 'display': {'vegas_scroll': { + 'max_plugin_width_ratio': 3.0 + }} + }) + assert cfg.max_plugin_width_ratio == 3.0🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/test_vegas_density.py` around lines 784 - 789, Add an explicit opt-in assertion to test_width_cap_is_off_by_default by constructing VegasModeConfig.from_config with max_plugin_width_ratio set to 3.0 and verifying the resulting value remains 3.0, while preserving the existing default-value assertions.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@test/test_vegas_density.py`:
- Around line 784-789: Add an explicit opt-in assertion to
test_width_cap_is_off_by_default by constructing VegasModeConfig.from_config
with max_plugin_width_ratio set to 3.0 and verifying the resulting value remains
3.0, while preserving the existing default-value assertions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 680fb3cc-b35a-47b2-b5ea-ea37f99217e0
📒 Files selected for processing (5)
config/config.template.jsondocs/CONFIG_REFERENCE.mdsrc/vegas_mode/config.pytest/test_vegas_density.pyweb_interface/templates/v3/partials/display.html
Defaulting the cap off must not quietly remove it. Asserts that an explicit ratio is honoured and validates, alongside the existing check that omitting it means uncapped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
1 participant
Why
Vegas plugins read as "cut off early" or "starting in the middle". That is the per-plugin width budget in
plugin_adapter.py, not the scroll engine —overflow_mode=rotateis designed to resume mid-content on each appearance, so the symptom was the feature working as specified.Measured over a 17-plugin fleet on a 512px panel, the cap turned out to be a bad trade. Only four plugins were ever wide enough to hit the
3.0default:So it bought nothing on thirteen plugins while costing two visible faults on four:
What changed
max_plugin_width_ratiodefaults to0(uncapped), so every plugin contributes all of its content and is always entered at its beginning. Updated in the dataclass, thefrom_configfallback,config.template.json,CONFIG_REFERENCE.md, and the web UI's help text and fallback value.The cap is unchanged and still available.
vegas_max_width_screensstill caps an individual plugin, which is where the knob belongs — a genuinely long ticker is a property of that plugin, not of the fleet.Verification
test_width_cap_is_off_by_defaultadded; 195 tests pass acrosstest_vegas_density.py,test_vegas_continuous_refresh.py,test_vegas_render_pipeline_recompose.py.Not addressed here
Two defects in the capping path, now dormant at the default but live for anyone who sets a cap:
_crop_to_budgethas no minimum window size, hence the 348px runt above.Happy to follow up on those separately.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Udr6MfaFLUPhX5Fgo67Jf5
Summary by CodeRabbit
Improvements
0.0means unlimited width.Tests