Repository navigation
feat(shot): lay out with a device's safe area with --safe-area - #50
Merged
Merged
Conversation
shot --safe-area <top>,<bottom> (and semantics, and shot(safeArea: SafeAreaInsets(...))) lays every preview out with those safe area insets in logical pixels, which flutter test reports as none. The view reports them as its padding and view padding, so an AppBar grows by the top inset and a SafeArea keeps out of them as on the device; with --keyboard, the keyboard absorbs the bottom inset from the padding but not from the view padding. The status bar and home indicator are not drawn. The run records safe_area, shot prints it, and diff prints both runs' when they differ and returns it as ShotSetup.safeArea; it is not part of shot ids. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner
Author
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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 #49.
flutter testlays the app out without a safe area: the view reports no padding (MediaQuery.paddingOfandviewPaddingOfareEdgeInsets.zero), as no phone does. A screen shot that way has itsAppBar59 points higher than on an iPhone, and aSafeAreaor a bottom bar that pads itself by the padding sits flush with the edges, so the image an agent attached was not the screen it was implementing.How it works
shutter shot --safe-area <top>,<bottom>(andsemantics) lays every preview out with those insets in logical pixels; from Dart,shot(safeArea: SafeAreaInsets(top:, bottom:)). There is no default, as with--keyboard: insets differ by device.viewPaddingandpaddingto the insets. With--keyboard, the keyboard absorbs the bottom inset from the padding but not from the view padding, as the engine documents for a device (FlutterView, "Insets and Padding").shootrejects insets that are not ≥ 0 and finite with exit 64; the CLI rejects anything but two numbers.safe_areainmanifest.json,shotprints it, anddiffprints both runs' when they differ and returns it asShotSetup.safeArea. It is not part of shot ids.Tests
test/e2e/device_test.dart: aSafeAreainside a red box keeps out of--safe-area 10,5(red bands at the top and bottom, none without the option); with--keyboard 20the bottom band is gone whileMediaQuery.viewPaddingOfstill reads the insets;diffprintssafe_area.Docs
doc/manual.mdgains a Safe area section; runs, output, and commands name the option.doc/agent.md, the README, and the CHANGELOG cover it.🤖 Generated with Claude Code