@mahersafadii Slightly correction: It’s not because the PR is massive, but the project is massive. Sometimes changes of small LOC can have massive impact and thus must be discussed thoroughly, for example bumping the minimal version of Android. Similar for this one.
@jezell@mahersafadii Splitting into smaller PRs and steps is also for the convenience of reviewing. Writing something new is hard, and reviewing them is even harder, because reviewers are the last guardians of code correctness. It’s important that reviewers really approve (cont.)
@jezell@mickrich384@mahersafadii We had to write pages of design docs as well. And it’s becaude they really help. I wrote design docs for almost all big projects of mine, and I only regret the cases when I did not write enough - the keyboard was not discussed thoroughly and admittedly it didnt turn out well
@RydMike@mahersafadii@luke_pighetti In my algorithm, assume it has equal x radii and y radii, if 2 r_x >= width, then the width sides are circular arcs. The y sides continue to be continuous rounded borders. (Basically the x and y sides are separated/stitched together.) I'm pretty sure this is how Swiftui works.
@luke_pighetti@mahersafadii@RydMike During my research I indeed used screenshots of SwiftUI's shapes as reference and derived the formula by pixel comparison. The theoretical result is pretty good (see attached). The PR, though, focus on the practical side, i.e. how it runs in real apps and can be used by users :)