It's a common use case to want to mix up buttons with outlined buttons and an attribute facilitates reusing layouts with different themes.
PiperOrigin-RevId: 234189427
Add shapeAppearance and shapeAppearanceOverlay attributes. These attributes combine to support shapes theming. ShapeAppearance is modeled after TextAppearance. A shapeAppearance attribute contains a style reference that is meant to be defined at the theme level. Since changing anything defined in the shapeAppearance would clobber everything else in the ShapeAppearance, the shapeAppearanceOverlay attribute is provided for clients to modify the shapeAppearance.
PiperOrigin-RevId: 215273652
Add shapeAppearance and shapeAppearanceOverlay attributes. These attributes combine to support shapes theming. ShapeAppearance is modeled after TextAppearance. A shapeAppearance attribute contains a style reference that is meant to be defined at the theme level. Since changing anything defined in the shapeAppearance would clobber everything else in the ShapeAppearance, the shapeAppearanceOverlay attribute is provided for clients to modify the shapeAppearance.
PiperOrigin-RevId: 215242636
This was due to FloatingToolbar using <Button> for its layouts in API 23-25, which got automatically inflated to <MaterialButton> via the custom view inflater in MDC themes. However, the default MaterialButton styling (especially backgroundTint) was overriding the styling in the <Button>, resulting in a broken FloatingToolbar. This issue was not encountered on API 24/25 since there were likely theme/style changes in those versions that override this Button. From API 26 onwards, FloatingToolbar uses a TextView and ImageView instead of Button.
PiperOrigin-RevId: 213517896
This commit updates MaterialComponents Snackbars to have margins and rounded corners, as well as makes Snackbars styleable at the app theme level via a snackbarStyle attribute.
PiperOrigin-RevId: 202141103
The editTextStyle is now implicitly set to Widget.AppCompat.EditText.
The background for this change is that all EditTexts in the theme were getting the filled box text field set on it rather than Widget.AppCompat.EditText. Because the TextInputEditText style is set via a ThemeOverlay, simply setting the correct style on the TextInputEditText wouldn't remove the attributes set in the filled box ThemeOverlay. This commit sets textInputStyle to Widget.Design.TextInputLayout to work around that.
This commit also adds a legacy text field demo. This should help ensure that the pre-existing text field isn't changed as a result of other modifications to the text field.
PiperOrigin-RevId: 198758642
Move to use native android:padding attrs instead of custom boxPadding attributes for text fields. This is accomplished by creating box styles for TextInputEditText, and setting android:padding attributes in those.
The TextInputLayout box styles set the appropriate TextInputEditText style on its child by wrapping the TextInputEditText style in theme overlays. This is kind of neat, since it allows for the user not to have to set a style on both the TextInputLayout and TextInputEditText - the user does not even have to know about the TextInputEditText styles with this pattern. It should also help clear up some confusion over where to set the hint and other areas of haziness between TextInputLayout and TextInputEditText.
The default editTextStyle is set to the filled box style, to match the default TextInputLayout style.
This change removes the box padding attributes, and it also removes the dimension resources in favor of setting them in the style to improve readability.
This commit also changes TextInputEditText constructors to both use a theme attribute in the 3-arg constructor and call through to the TextInputEditText overloaded constructors rather than call the super's constructor from each. This allows the theme attribute set in the theme overlays to take effect.
PiperOrigin-RevId: 198051251
