Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

CLAs look good, thanks!

Where does it get resolved? Or is it passed through to something that already accepts EdgeInsetsGeometry?

(this will need tests)

For almost every padding enabled widget in Flutter we are able to set a padding either from a left-top-right-bottom or start-top-end-bottom because the padding property itself is a EdgeInsetsGeometry and we can assign values of type EdgeInsets or EdgeInsetsDirectional to it (child classes).

For InputDecorator this was not the case and i believe it is an implementation mistake. Currently we are unable to do the following:

new InputDecorator(
contentPadding: new EdgeInsetsDirectional...()
);

Above code will cause a compile-time error.

I think this is a good improvement to make however I don't think this is the right way to make it.

InputDecoration.contentPadding and InputDecorationTheme.contentPadding should be EdgeInsetsDirectional and _InputDecoratorState should resolve contentPadding based on Directionality.of().

Where are the EdgeInsets values actually used? Are they just passed on to Paddings or such, or are they directly used somewhere?

They're directly used (in a way where start/end resolution matters) by the InputDecorator's renderer at performLayout() time

Ah yeah in that case this patch will indeed not work, and we'll have to resolve them before use. I'm surprised the code above compiles without analyzer warnings, actually.

@xclud Will you be able to continue working on this (to address the comments above)? It's totally fine if not; we can take it over (though it might take longer). I'm just asking because I'm trying to clean out our review queue.

@Hixie I want to bring your attention to the field type of contentPadding which is EdgeInsets in the InputDecoration class.

On the other hand, for the rest of the Widgets padding field is of type EdgeInsetsGeometry. Take SingleChildScrollView as an example, here is the padding field:

final EdgeInsetsGeometry padding;

I believe the InputDecoration case is a mistake. Being EdgeInsetsGeometry allows us to use a value of type either EdgeInsets or EdgeInsetsDirectional.

Yes, it's definitely a mistake. The fix is not just to change the type though. We have to change the type, and resolve them (using EdgeInsertsGeometry.resolve) before using them.

I'm making an InputDecoration change now, will fix this as well.

@HansMuller Is this resolved now?

This was fixed in #17292

Thank you for the great job. Fixed.