Developer guide: regenerate three Components figures from their own samples - #5737
Merged
Merged
Conversation
…amples The check/radio, MultiButton and SpanLabel figures were 320x480 captures from the HVGA era. They now render through the figure harness under Android Material at a current phone profile. The samples move with them. Each figure's build() carries the exact tagged region the chapter used to include from a snippet fixture, and the chapter now includes it from the figure class, so the listing beside a picture is the code that drew it. A compile-only fixture and a screenshot are two sources for one example, and nothing keeps them in step -- which is how the chapter came to caption an iOS button render with a claim about borders that the sample beside it never demonstrated. One canonical variant each, on Android Material, because the subject is the component rather than the platform. Android is the right single choice: these render through the port's bundled Roboto, which is what Material 3 specifies, while an iOS Modern render comes out in Roboto rather than SF and is typographically wrong -- worth having only where the platform difference is the point, as in the button pair. GuideFigure's contract now says a figure MAY show its form, which these samples do because that is what a reader would write. The renderer prepares the returned form at the target geometry either way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0cb0f39b4b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
…s them com.codename1.ui's package documentation embeds 36 guide screenshots as absolute URLs under /img/developer-guide/. Nothing in this repository produces that path: scripts/website/build.sh rsyncs docs/developer-guide/ into the site's static/developer-guide/, preserving subdirectories, so these files are served from /developer-guide/img/ instead. The URLs are rewritten to that shape and each one is now checked to resolve to a file that ships. One of them was newly broken by this branch rather than merely misspelt. components-button.png is deleted by the figure harness change -- its caption claimed iOS draws no border on a button, which Liquid Glass made false -- and the javadoc still pointed at it. It now takes the iOS render of the pair that replaced it. The three figures this PR regenerates moved under img/generated/ and their URLs move with them. Because the URLs really are derived from the file layout, a comment beside the package declaration records that, so the next move under docs/developer-guide/img knows it has to bring them along. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
shai-almog
force-pushed
the
devguide-figures-components
branch
from
September 7, 2026 17:47
01c9644 to
91f3fc9
Compare
Contributor
Cloudflare Preview
|
Collaborator
Author
|
Compared 151 screenshots: 151 matched. Native Android coverage
✅ Native Android screenshot tests passed. Native Android coverage
Benchmark ResultsDetailed Performance Metrics
|
Collaborator
Author
|
Compared 181 screenshots: 181 matched. |
… tolerance CI rendered all three differently from this Mac. Not a flake and not a docs bug: the differing pixels fall in narrow column runs exactly the width of an icon, at the icon positions, and every text column is byte-identical, with both renders the same size. Java2D rasterizes the same glyph from the same bundled font at the same size slightly differently on macOS and Linux. The three figures added alongside these that carry no FontImage glyph reproduced byte-for-byte, which is the control. Measured: 732/134561 pixels (0.544%) for the check and radio figure, 460/208181 (0.221%) for MultiButton, 368/129244 (0.285%) for SpanLabel, worst channel delta 134 to 136. The committed images are now the CI runner's own output, so the gate that actually runs compares byte-for-byte and the sidecar budget only covers regenerating a figure on a developer's Mac. Each budget is set just above its own measurement rather than one loose number shared by all three, and maxChannelDelta stays at the 160 the existing sidecar uses -- clear of the measured worst, and still failing a solid overwrite. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
Developer Guide build artifacts are available for download from this workflow run:
Developer Guide quality checks: |
Collaborator
Author
|
Compared 160 screenshots: 160 matched. Benchmark Results
Detailed Performance Metrics
|
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
2 participants
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.
Stacked on #5734 (based on
devguide-figure-harness, not master). Review ormerge that one first; this rebases onto master cleanly once it lands.
The check/radio,
MultiButtonandSpanLabelfigures were 320x480 capturesfrom the HVGA era. They now render through the figure harness under Android
Material at a current phone profile.
The samples move with the pictures
Each figure's
build()carries the exact tagged region the chapter used toinclude from a snippet fixture, and the chapter now includes it from the figure
class. The listing beside a picture is therefore the code that drew it.
A compile-only fixture and a screenshot are two sources for one example and
nothing keeps them in step -- which is how this chapter came to caption an iOS
button render with a claim about borders that the sample beside it never
demonstrated.
One canonical variant each
Android Material, because the subject is the component rather than the platform.
Android is the right single choice: these render through the port's bundled
Roboto, which is what Material 3 specifies, whereas an iOS Modern render comes
out in Roboto rather than SF and is typographically wrong -- worth having only
where the platform difference is the point, as in the button pair from #5734.
GuideFigure's contract now says a figure MAY show its form, which thesesamples do because that is what a reader would write; the renderer prepares the
returned form at the target geometry either way.
Gates run locally: 31/31 figures match, structure, xrefs, snippet validation,
missing-code-blocks, links, unused images, capitalization, asciidoctor
--failure-level WARN, Vale 0, LanguageToolstatus: ok0, controlcharacters, copyright headers.
Note these three carry
FontImagematerial glyphs, whose antialiased edges maynot reproduce byte-for-byte across platforms. If CI reports a difference I will
look at the actual delta and either fix the cause or add a justified
.tolerancesidecar -- not guess a value up front.🤖 Generated with Claude Code