Let a progress ring's art be swapped for art of another size - #31
Merged
Conversation
The resize half of #22 holds: scaleRing is the one sizing rule, and the size field, the corner drag, the arrow keys and a group resize all go through it. Replacing the bitmap did not — replaceImageFx writes the new asset and nothing else, so a ring kept the circle its old art had. That circle is meta.w/h, which is what drawSector pivots the filled sector around: swap a 284px ring for a 64px one and the sector still swings around a 284px centre, with the art anchored to the side of a circle it no longer fills. On screen that reads as "the image can't be replaced". A swap is a resize by another name, so it goes through the same rule: fitRingsToArt scales every ring drawing the asset (assets are shared) by the factor the new pixels bring. And scaleRing now carries spec.radius through the with-art case as well — 0x5b never writes one, but an editor-made ring is 0x5a and does, so replacing or resizing its art otherwise exported a diameter the widget no longer had, the same defect addRingImageFx already fixes on the way in. Two regression tests, both checked to fail against the old code. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PgJ39ZDcxiHJt3uabAgSL8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #22.
Resize — already fixed on
mainby "Give a ring one sizing rule, and stop the resize paths disagreeing". Verified rather than re-done:scaleRingis the single sizing rule, and the inspector's size field, corner drags, arrow keys and a group resize all go through it. A ring with no art resizes through its arc spec; one with art rescales its pixels and moves its own circle with them.Replacing the art — this PR.
replaceImageFxwrote the new asset and nothing else, so a ring kept the circle its old bitmap had. That circle ismeta.w/h, which is whatdrawSectorpivots the filled sector around: swap a 284px ring for a 64px one and the sector still swings around a 284px centre, with the art anchored to the side of a circle it no longer fills. On screen that reads as "the image can't be replaced".A swap is a resize by another name, so it now goes through the same rule —
fitRingsToArtscales every ring drawing the asset (assets are shared) by the factor the new pixels bring.scaleRingalso carriesspec.radiusthrough the with-art case now: 0x5b never writes a radius, but an editor-made 0x5a ring does, so replacing or resizing its art exported a diameter the widget no longer had — the same defectaddRingImageFxalready fixes on the way in.Two regression tests, both checked to fail against the old code. Full suite: 193 passing;
check,lintandformat:checkclean.🤖 Generated with Claude Code
https://claude.ai/code/session_01PgJ39ZDcxiHJt3uabAgSL8