Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Merged
merged 42 commits into from
Jul 3, 2018

Conversation

jonahwilliams
Copy link
Member

@jonahwilliams jonahwilliams commented Jun 11, 2018

  • Adds a new ThemeData property called materialTapTargetSize which configures minimum tap targets

Defaults to MaterialTapTargetSize.padded.

  • Increase size of checkbox, switch, and radio button to 48 by 48
  • Increase material button minimum tap target height to 48
  • Increase chip minimum height to 48.
  • update chip tap areas to be more forgiving

The previous size can be obtained using MaterialTapTargetSize.shrinkWrap, either by providing to theme data or through the new constructor params

Succeeds:

Fixes #615

@jonahwilliams
Copy link
Member Author

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;
Copy link
Contributor

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.

@Hixie
Copy link
Contributor

Hixie commented Jun 11, 2018

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).

@jonahwilliams
Copy link
Member Author

I'll go ahead and merge all of the other PRs into this one then.

@jonahwilliams
Copy link
Member Author

jonahwilliams commented Jun 18, 2018

I have a solution - in the gif below I've increased the padding significantly and I tap below, inside of, then above the button. If the "_RedirectingHitDetectionWidget " I added in button is reasonable, I can move it to material so i can reuse it for chips as well.

splash_outside

@jonahwilliams
Copy link
Member Author

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));
}
}
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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);
Copy link
Contributor

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

Copy link
Member Author

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);
Copy link
Contributor

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

Copy link
Member Author

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 {
Copy link
Contributor

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".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@jonahwilliams
Copy link
Member Author

Still need to expand test coverage for the new hit detection behaviors

@jonahwilliams
Copy link
Member Author

I've added test cases to cover the new material button ink behavior and the expanded hit area of chips, PTAL

@jonahwilliams
Copy link
Member Author

Friendly ping @goderbauer , @Hixie

@goderbauer
Copy link
Member

Can you update the PR description? Looks like the PRs mentioned there have been merged into this one?

@jonahwilliams
Copy link
Member Author

Done

Copy link
Member

@goderbauer goderbauer left a 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?

@jonahwilliams
Copy link
Member Author

Yes, I will make sure to send a follow-up announcement

@jonahwilliams jonahwilliams merged commit 989f574 into flutter:master Jul 3, 2018
@jonahwilliams jonahwilliams deleted the tap_target_flag branch July 3, 2018 17:56
@jonahwilliams jonahwilliams restored the tap_target_flag branch July 3, 2018 20:42
@jonahwilliams jonahwilliams deleted the tap_target_flag branch July 3, 2018 20:42
@jonahwilliams jonahwilliams restored the tap_target_flag branch July 3, 2018 20:42
jonahwilliams added a commit that referenced this pull request Jul 3, 2018
jonahwilliams added a commit that referenced this pull request Jul 3, 2018
jonahwilliams added a commit that referenced this pull request Jul 9, 2018
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Flat buttons are supposed to have a 48px high tap target
5 participants