No visible or public API changes. Internal refactor.
This change adds the notion of a horizontal positioning reference. This will make it so that different styles can have different horizontal padding values.
Prior to this change, there was only one "horizontal padding" value. This change separates it into two values: one for the padding between leftmost and rightmost views and the left and right edges of the TextControl, and one for the padding between subviews of the TextControl. These two values live on a horizontal positioning reference object. Different styles will one day have different horizontal positioning reference objects.
For now only TextControl text fields will use this.
It's a lot of files but trivial changes in most, if not all, of them.
PiperOrigin-RevId: 314748534
This follow up PR for #9731 includes the following:
* MDCTextControlLabelState has been renamed to MDCTextControlLabelPosition
* Identical methods in MDCTextField and MDCBaseArea have been consolidated as C functions in shared locations.
* A few methods have been renamed.
* A few pragma marks have been renamed.
Related to #9407.
Some internal snapshot tests force RTL by setting the semantic content attribute. The "is RTL" logic in MDCBaseTextFields up to this point only looked at effective layout direction. This change makes it so that it checks if either RTL or LTR semantic content attributes are being forced before consulting effective layout direction.
PiperOrigin-RevId: 293201200
This change makes it so that the MDCBaseTextField invalidates its intrinsic content size when either the view's width or the view's layout's calculatedHeight has changed since the intrinsic content size was last calculated.
PiperOrigin-RevId: 293141339
## UPDATED PR DESCRIPTION:
**NOTE: [cl/290296411](http://cl/290296411) must be patched into whatever release includes this PR.**
There were requests to break it up further. With the latest changes, it will look like this in the future:
//components/TextControls:Shared # shared public types
//components/TextControls:BaseTextFields
//components/TextControls:FilledTextFields
//components/TextControls:FilledTextFieldsTheming
//components/TextControls:OutlinedTextFields
//components/TextControls:OutlinedTextFieldsTheming
//components/TextControls:BaseTextAreas
//components/TextControls:FilledTextAreas
//components/TextControls:FilledTextAreasTheming
//components/TextControls:OutlinedTextAreas
//components/TextControls:OutlinedTextAreasTheming
//components/TextControls:FilledInputChipView
//components/TextControls:FilledInputChipViewTheming
//components/TextControls:OutlinedInputChipView
//components/TextControls:OutlinedInputChipViewTheming
//components/private/TextControlsPrivate: Shared # shared private types
//components/private/TextControlsPrivate:OutlinedStyle
//components/private/TextControlsPrivate:FilledStyle
This would make it easier to sunset/retire a specific style of a specific text control type, for example.
## ORIGINAL PR DESCRIPTION:
This PR is an attempt to satisfy the recent requests to break up the Cocoapods subspecs and Bazel targets for TextControls.
~**NOTE: [cl/289710430](http://cl/289710430) must be patched into whatever release includes this PR.**~
**ANOTHER NOTE: This PR will break any third party people who depend on TextControls via Cocoapods and have not pinned to a specific version of our library.**
This PR takes the following Cocoapods subspecs:
TextControls
TextControls+Theming
And breaks them up into these ones:
TextControls
TextControls+TextFields
TextControls+TextFieldsTheming
private/TextControlsPrivate
Similarly, it takes the following bazel targets:
//components/TextControls
//components/TextControls:Theming
And breaks them up into these ones:
//components/TextControls
//components/TextControls:TextFields
//components/TextControls:TextFieldsTheming
//components/private/TextControlsPrivate
Where before a third party client would have had the following in their Podfile:
`pod 'MaterialComponents/TextControls'`
They would now have:
`pod 'MaterialComponents/TextControls+TextFields'`
When I started this work I originally planned to have there be top level components for each of the TextControls that all depended on a shared private component. However, I quickly remembered that all the text controls shared some public types too. At some point I decided it make make sense to make use of extensions.
In order to satisfy pod lib lint I had to add some dummy source files and dummy test files. The dummy test files could potentially have some stuff in there if we want to validate the enums they refer to somehow...
Closes#9405.
