Add test 'border_overlap' theming to somewhat control overlapping of shapes and their borders #660
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Artefacts reported in #659 are hard to address universally - we want to have soft corners, but also to support transparency and also support a wide variety of curves and have flexibility about where shapes will be.
A potential solution is to pass over control of the 'overlap' parameter to users so they can tweak it for their situations.
Previously it was hard coded to "0" for rounded corner buttons and to "1" for ellipse shaped buttons. Clearly I've tinkered with various values in the past to try and solve the various artefacts, but no value solves all problems.
In this PR 'border_overlap' is added (but not documented yet) as a miscellaneous theming parameter and I've set it to "1" by default everywhere as I think this is probably the most widely applicable default value.
I'll see how the default value of 1 goes down in wider testing in the next release and if the hidden theming value is helpful (or not) before documenting it in the future.