-
Notifications
You must be signed in to change notification settings - Fork 28.5k
Add flag to ThemeData to expand tap targets of certain material widgets #18369
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
…nform to android a11y scanner
Not sure whether we should explicitly call out the changes to each widget on the documentation - If so I would prefer to do that on the PR where the change is made |
@@ -483,6 +488,10 @@ class ThemeData extends Diagnosticable { | |||
/// Defaults to the current platform. | |||
final TargetPlatform platform; | |||
|
|||
/// Whether to expand the tap target of certain material widgets to a minimum | |||
/// of 48dp by 48dp. | |||
final bool expandedTapTargetSize; |
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 could be an enum or a double, but I don't think it makes sense for it to be a bool.
We shouldn't check this in separate from all the breaking changes that will rely on it. It should all land at the same time. Otherwise we run the risk of people setting the flag and then us changing the behaviour of the flag (especially since tomorrow is the cut-off for the next beta, so there'd likely be a whole cycle between this commit and the one that uses the flag). |
I'll go ahead and merge all of the other PRs into this one then. |
I guess chip changes are still TBD for chips with two actions, but it will likely require splitting a chip into two tap targets. |
return false; | ||
return child.hitTest(result, position: size.center(Offset.zero)); | ||
} | ||
} |
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 is an interesting approach.
Why can't we just make the single GestureDetector bigger though?
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.
The GestureDetector/InkWell/Material is a delicate ecosystem.
InkWell (which contains the gesture detector) uses context to find a parent material where it draws the splashes. Any increase in the size of the gesture detector, which is sized by the material, necessarily increase the material size which would increase the visible appearance of the button.
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.
Oh, right, I forgot that buttons had their own Material...
Please add a test to make sure that only one of the GestureDetectors gets the pointer down event (which I believe this code does as you wrote it but it's something we should make sure we don't regress since it's so subtle).
Also please make sure there's a test that when you tap inside the button, the splash starts where you tapped, but when you tap outside the button, it starts wherever we decided it should start.
/// The primary purpose of this widget is to allow padding around [Material] widgets | ||
/// to trigger the child ink feature without increasing the size of the material. | ||
class _RedirectingHitDetectionWidget extends SingleChildRenderObjectWidget { | ||
const _RedirectingHitDetectionWidget({this.constraints, Widget child}) : super(child: child); |
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.
widgets should always take keys
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.
Fixed
|
||
@override | ||
RenderObject createRenderObject(BuildContext context) { | ||
return _RedirectingHitDetectionRenderObject(constraints); |
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 should still have a new
until we have the lint that prevents us from using new
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.
Fixed
} | ||
} | ||
|
||
class _RedirectingHitDetectionRenderObject extends RenderConstrainedBox { |
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.
convention for naming these is "RenderFoo", with the widget being called "Foo".
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.
Fixed
Still need to expand test coverage for the new hit detection behaviors |
I've added test cases to cover the new material button ink behavior and the expanded hit area of chips, PTAL |
Friendly ping @goderbauer , @Hixie |
Can you update the PR description? Looks like the PRs mentioned there have been merged into this one? |
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.
LGTM
Did we announce this as a breaking change already?
Yes, I will make sure to send a follow-up announcement |
Defaults to
MaterialTapTargetSize.padded
.The previous size can be obtained using
MaterialTapTargetSize.shrinkWrap
, either by providing to theme data or through the new constructor paramsSucceeds:
Fixes #615