-
Notifications
You must be signed in to change notification settings - Fork 29.8k
Add clipBehavior to widgets with clipRect #55977
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Gold has detected one or more untriaged digests on patchset 9. |
6223a26 to
9b1569d
Compare
|
Golden file changes have been found for this pull request. Click here to view and triage (e.g. because this is an intentional change). Changes to golden files are considered breaking changes, so consult Handling Breaking Changes to proceed. While there are exceptions to this rule, if this patch modifies an existing golden file, it is probably not an exception. Only new golden file tests, or downstream changes like those from skia updates are considered non-breaking. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. Changes reported for pull request #55977 at sha 9b1569df6c88349372787e7df5597b8d83582942 |
|
This appears to be breaking some tests (see cirrus). |
|
@goderbauer : thanks! Just fixed them. |
|
Gold has detected one or more untriaged digests on patchset 10. |
|
Golden file changes are available for triage from new commit, Click here to view. Changes reported for pull request #55977 at sha dc4ed1291ab026257428c0d631709e60802b3f84 |
|
Golden file changes are available for triage from new commit, Click here to view. Changes reported for pull request #55977 at sha c2e2ad91876e292dfc598b71e8226569b34a2bfe |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering whether we really need this class. The renderobjects in question could just use the mixin directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added ClippableRenderBox for SingleChildScrollView respects clipBehavior test: https://github.com/flutter/flutter/pull/55977/files#diff-dc4070bb6bd99e8491da558051581285R45. Its render object _RenderSingleChildViewport is private so I have to create a parent render object class for testing... I'd love to remove ClippableRenderBox if there's another way to test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you re-write the test as follows:
final dynamic renderObject = tester.renderObject.where((RenderObject o) => o.runtimeType.toString() == '_RenderSingleChildViewport');
expect(renderObject.clipBehavior, equals(Clip.hardEdge));Note the cast to dynamic which should allow you to call whatever you want on it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we definitely shouldn't add to our public API surface just to work around Dart testability limitations. Better to just go fix Dart.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's strange that there are two flags here to control whether to clip or not. clipToSize and clipBehavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to remove clipToSize and overflow! My previous concern was how it affects our breaking change migration. My old post https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ seems to still cover this PR if I don't remove clipToSize and overflow. But after a second thought, I think it's better to remove them immediately so the old code would result in compile errors instead of runtime errors saying that clipToSize/overflow is incompatible with the default clipBehavior. My next patch will remove them, and I'll write a new breaking change announcement with migration suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, it's strange that there are two flags to control clipping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ClippableRenderBox claims that the default is none.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean that the auto-generated API doc for RenderViewportBase will say that the default is Clip.none instead of Clip.hardEdge because ClippableRenderBox defaults it to Clip.none? Some ClippableRenderBox subclasses default to Clip.none while some default to Clip.hardEdge. I'd like to know if there's a way to specify/modify in each subclass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think dartdoc provides any affordances for this, but I am no dartdocs expert.
But the auto-generated documentation for all classes that extend ClippableRenderBox or mixin the mixin and set the default to something other then "none" will have incorrect documentation with the current approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't bother with the mixin. Just inline the duplicate code. It's not complex logic, and it might not be identical everywhere (as shown by the different defaults, for one).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in the constructor its set to hardEdge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This comment applies to some other places in the PR as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Forget to change after copy/paste... Fixed for all 5 widgets now.
|
Can you please fill out the PR template. The section about breaking changes would be most relevant. What's the plan to make this breaking change? Will this not break many customers in unsuspecting ways? |
liyuqian
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filled out the PR template with the breaking change section. I'll come up with a design doc with the new template, contact the DevRel team, and send out an updated migration guide (the old one is https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ) to flutter-dev or flutter-announcement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added ClippableRenderBox for SingleChildScrollView respects clipBehavior test: https://github.com/flutter/flutter/pull/55977/files#diff-dc4070bb6bd99e8491da558051581285R45. Its render object _RenderSingleChildViewport is private so I have to create a parent render object class for testing... I'd love to remove ClippableRenderBox if there's another way to test it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to remove clipToSize and overflow! My previous concern was how it affects our breaking change migration. My old post https://groups.google.com/g/flutter-dev/c/XMHE0XdsXxI/m/nonrNQpbBAAJ seems to still cover this PR if I don't remove clipToSize and overflow. But after a second thought, I think it's better to remove them immediately so the old code would result in compile errors instead of runtime errors saying that clipToSize/overflow is incompatible with the default clipBehavior. My next patch will remove them, and I'll write a new breaking change announcement with migration suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will remove.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean that the auto-generated API doc for RenderViewportBase will say that the default is Clip.none instead of Clip.hardEdge because ClippableRenderBox defaults it to Clip.none? Some ClippableRenderBox subclasses default to Clip.none while some default to Clip.hardEdge. I'd like to know if there's a way to specify/modify in each subclass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Forget to change after copy/paste... Fixed for all 5 widgets now.
|
Gold has detected one or more untriaged digests on patchset 12. |
1 similar comment
|
Gold has detected one or more untriaged digests on patchset 12. |
|
Golden file changes are available for triage from new commit, Click here to view. Changes reported for pull request #55977 at sha 89c34d5e5e0838c47963bcdf9989d231326e327a |
|
Gold has detected one or more untriaged digests on patchset 13. |
|
Golden file changes are available for triage from new commit, Click here to view. Changes reported for pull request #55977 at sha 8367ad27807951a25080410411a91bf8c124367f |
|
Does this change cause any trouble when rolled into google3? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't belong in object.dart. It's way too specific.
Is there any reason we wouldn't just duplicate this code everywhere rather than using mixins? Mixins aren't free (they add more classes to our class hierarchy, etc). I don't know how well they interact with tree shaking either. We don't have any trouble duplicating other fields. Why is this one special?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will also fix the documentation trouble I mentioned in the other comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the Mixin. BTW, I'm curious if we had any experiments on the Mixin's impact on app size? For example, what's the Flutter gallery's size difference between (1) copying a small piece of code dozens of times and (2) defining a small mixin which is reused dozens of times?
Those widgets are NestedScrollView and ShrinkWrappingViewport.
)" (flutter#58344)" This reverts commit 1d395c5.
…r#55977" (flutter#59364) * Revert "Revert "Add clipBehavior to widgets with clipRect (flutter#55977)" (flutter#58344)" This reverts commit 1d395c5. * Add missed Overflow
|
Good feature. |
|
@urusai88 : they're being added in #63147 |
…r#55977" (flutter#59364) * Revert "Revert "Add clipBehavior to widgets with clipRect (flutter#55977)" (flutter#58344)" This reverts commit 1d395c5. * Add missed Overflow
Description
We add
clipBehaviortoEventually, the first 4 of them will be default to
Clip.nonewhile the remaining 6 of them are default toClip.hardEdge.In the current PR, all of them are still default to
Clip.hardEdgeto not break some Google usages. Once we've updated the code inside Google, we'll update the clipBehavior.Related Issues
This is a continuation of #18057, and this fixes #21830
Tests
Unit tests added to each modified widget and render object.
Breaking Change