`MDCShapedView` has properties to configure the elevation and shape generator but no properties to configure the border color/width. In order to do so, one must cast the view’s layer to `MDCShapedShadowLayer` and set its border color/width. (There is also no property exposing the underlying `MDCShapedShadowLayer`.)
PiperOrigin-RevId: 351710014
This bug was happening when an MDCShapedShadowLayer has an empty frame and a positive shapedBorderWidth value, and a path is assigned. The MDCShapedShadowLayer was attempting to calculate a value in relation to the bounds of the MDCShapedShadowLayer, which in turn was resulting in a divide by zero.
This change adds safeguards around the divisions to ensure that a division does not occur if the width or height are sufficiently close to zero.
PiperOrigin-RevId: 322768484
This error can happen when an MDCShapedShadowLayer has an empty frame and a positive shapedBorderWidth value, and a path is assigned. There is a divide by zero in the logic introduced in cl/322615641.
In a subsequent change I will fix the bug and update the test accordingly.
PiperOrigin-RevId: 322689400
There is a visual difference when using lineWidth instead of borderWidth due to lineWidth drawing on the path, and borderWidth insetting from the path.
To resolve this, the path is made smaller by half the width of the line, thus to create a similar visual appearance as if borderWidth was set.
PiperOrigin-RevId: 322615641
This is the third and last part of the migration of moving the Shape libraries away from the private/ folder. Continuation to PR: #6664 and #6495
Tracking bug, progress and more details can be found here: #6494
This resolves#6494
Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
**We have completed steps 1 to 6, This PR concludes step 7 and the entire migration**
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
This is the first part of the migration of moving the Shape libraries away from the private/ folder.
Tracking bug, progress and more details can be found here: #6494
"Because Shapes and ShapeLibrary have been used in production and are an integral part of the shape scheme and theming. Moreover, with to stop the confusion of clients that the library should not be imported as it is under private, we want to migrate the Shape libs to be under components/ instead of components/private.
The migration will be a 7 step migration to not break clients internally.
1. move the folders to the new directory.
2. Make the old component's BUILD and Podspec targets depend on the new component (and nothing else).
3. Delete all implementation files from the old component.
4. Replace the contents of the old component's headers with import statements to the new component's header. If the new component has headers that match the old component's, then the new component's headers will need to be named uniquely for a period of time to allow clients to migrate over.
5. Once all clients have migrated from the old component, delete the old component. This is a breaking change.
6. If you had to create temporary header names in the new component, then in a separate release add the new headers that you want the new component to use. Move the content of the old headers into the new headers and replace the old headers with an import of the new headers. Migrate clients to the desired headers.
7. Once all clients have moved off of the old headers, delete the old headers.
Passes bazel build and pod build locally.
