"CornerRadius" is a misunderstanding.

[Splitwirez]

Hi,

Recently, while working on a PR to port the WinUI Expander style to Avalonia, I ran into some trouble stemming from how WinUI has a CornerRadius property on most controls, while Avalonia does not, and was reminded of an observation I made a while ago.

Metaphorically speaking, a CornerRadius property on all applicable controls (as is the case with BorderThickness) would ask the app developer a question:

• What should the radius of each corner of this control be?

But I feel that this is an unfortunate, perhaps-misguided conflation of two questions, which should be able to be answered independently of one another:

1. Which of these corners should be rounded?
2. What is the radius of a rounded corner?

This distinction is important. For example, take this example:

Here, we see three linked buttons, with only the left corners of the leftmost button and the right corners of the rightmost button being rounded. Currently, there is no built-in way to do this in Avalonia, WinUI, WPF, or any other XAML framework I know of, without forcibly answering both of the above questions. Avalonia's /template/ selector element reduces the amount of redundancy caused by this, but still doesn't solve the underlying problem.

This inability to answer one question without answering the other means a lot of hardcoded corner radii. These can and will later prove to be quite the nuisance, should the developer later decide to switch their app over to a new theme, or to provide multiple themes for the user to choose from, or if the app uses say, Avalonia's Fluent theme, and an Avalonia update changes the default corner radius for the Fluent theme, or any number of other such scenarios.

So that's the problem. Now, onto what I propose could be done about it.

For a Control library I've been working on, I experimented with a solution to this, which would allow these two questions to be answered independently of each other, as separate properties. That solution was as follows:

• A new class similar to CornerRadius but with four bools instead of four doubles, entitled CornerCurves
• An attached property for all applicable controls, called CornerCurves (of type CornerCurves, predictably enough)
• A value converter which takes in the attached CornerCurves property and a CornerRadius object, and produces a new CornerRadius object, with each corner's radius being either that of the original input CornerRadius if the CornerCurves object had true for that corner, or zero if the CornerCurves object had false for that corner

My exact implementation of this solution was flawed in various ways, but it did solve the problem: It allowed the app developer to answer only the first question ("Which of these corners should be rounded?"), while leaving the Avalonia theme still able to answer the second question ("What is the radius of a rounded corner?"), with no additional action from the developer being required.

I believe a similar solution can and should be implemented into Avalonia (albeit presumably not as an Attached property). I'm eager to do my part to do so, but want to hear what others think about both the problem and the proposed solution.

Also this would need a way to pass the value of a DynamicResource into a converter, or failing that a StaticResource...neither of which I've figured out a way to achieve, thus far...

---

UPDATE: Following the discussion which took place in the responses to this conversation, I've come to realize that, while this is a real and valid problem, it's not nearly as big of a deal to most as I expected, to the point where a solution to it - or at least a solution as drastic as the one I proposed - would be more trouble than it's worth to most.

Maybe Avalonia should just follow WinUI's example here. If that ends up being the plan, I'd be more than happy to do what I can to help make it happen.

[robloo]

Conceptually I think the answer here is simple. CornerRadius should be alongside BorderThickness property. In WPF/UWP BorderThickness is not part of UIElement or FrameworkElement, it is part of Border and Individual controls have this property themselves. I don't think its in all controls (even the ones that don't make sense) as you imply. Avalonia should do the same and only add it to Controls where it makes sense.

About the separation of concepts: only controls where a corner radius makes sense have the property. Setting any radius to zero turns it off. All information is clear. Your assumption that all controls have a corner radius property even if it doesn't make sense is incorrect I think. The existence of the property itself fills in the missing information you are looking for.

[Splitwirez]

I just thought of another idea: Take the approach I described initially, with the CornerCurves property, but instead of using a converter to combine them, add a CornerCurves property to the Border control, TemplateBind it in the template, and have the Border control itself do all the deciding-which-corners-to-round.

This would allow for DynamicResources to be used, while still allowing us to reap the benefits I initially highlighted.

[Splitwirez]

@maxkatz6 tbh, I feel like I've not done a very good job of explaining what I'm suggesting. I'm thinking it might be easier if I were to put together a draft PR to add the necessary plumbing for one or two controls to show how it could work, and then I would either finish the job if you folks give the go-ahead, or scrap it and help add the CornerRadius properties if you folks reject it.

Does that make any sense to you?

[maxkatz6]

Take the approach I described initially, with the CornerCurves property, but instead of using a converter to combine them, add a CornerCurves property to the Border control

I understand this approach, but for me it looks like a workaround build in the framework. For user it might be unintuitive why he has two APIs to choose what corners to display: CornerRadius and CornerCurves. It makes less sense if we will describe it as "CornerCurves used only in some specific use cases, when we bind to CornerRadius and our converters/setter is not good enough to make it simple".

[maxkatz6]

Assuming that we can't improve our Binding/DynamicResource integration or/and improve setters syntax in near time, I would say that I see adding CornerRadius property to every relevant control and using special converter to select corners (like it's done in WinUI) is more acceptable. Though I would like to hear opinion of other maintainers.

[maxkatz6]

But another issue with Bindings to CornerRadius properties is that we can't define that binding inside of template because of priorities issue:
CornerRadius="{Binding CornerRadius, RelativeSource={RelativeSourceTemplateBinding}, Converter={...}}"
will have Local priority value, that can't be overridden by user with his custom style. So we required to define this binding inside of Setter to have Style value, that can be overridden.

[robloo]

I should also add, I think the group of buttons you mentioned is an interesting example. This ideally should be a separate control (like ButtonGroup/SegmentedControl WinUI discussionor the RadioButtons group control). However, this could be generalized and a 'GroupedContainer' parent control could be created. This grouped container would take care of managing border/corner radius of children along with orientation. The container would have the properties that would apply to the group as a whole.

[robloo]

I think fundamentally, a more abstract 'group of controls' concepts is needed to address all your concerns. Conceptually, it isn't just CornerRadius to talk about here as you pointed out. Other types of properties could run into this situation (BorderThickness is a common one). Even something like sharing the Background between controls is relevant in the generalized discussion.

A hypothetical GroupContainer control would have it's own properties and logic (something like converters) determining how to apply properties to children. However, it isn't only styling concerns that would need to be addressed. Actual logic such as the segmented control example would need to be implemented as well. The group needs to be aware of pointer over, clicking, selection, etc. How is it possible to generalize this? This high-level of abstraction is probably more trouble than it's worth (even if it's possible). Perhaps making a 'StyleGroupContainer' is possible to make it clear logic must be handled elsewhere.

Anyway, I know I'm focusing on more than just CornerRadius but that seems to be unavoidable with the points you raise. At the end of the day for me the current level of abstraction we have now makes the most sense. Each control needs to manage things themselves but they also need to share as many properties as possible to make styling consistent (and sane). For the common/special cases RadioButtonGroup/ButtonGroup controls should be created.

Also, you are essentially questioning the original decision to add Border/Background properties to controls themselves. Again, this is just development convenience (and also was backwards compatible with Windows Forms at the time). There is no limit to how far this line of thinking can go though. There is constantly a struggle between optimizing ease-of-use with general-purpose code. Each control could have have a property for every single thing in the style that is configurable but that just doesn't make sense -- it also makes every control so different it's almost unusable. Things simply evolved to some point in the middle and the current level of abstraction seems to work for the vast majority of developers. I guess I just don't share your concerns overall.

[Splitwirez]

Funny you'd mention backgrounds...I'd previously thought about the potential value of being able to have, say, a gradient brush, which is drawn to an area relative to one control, but whose stops are positioned relative to another.

Who knew control properties could be so...uh..."philosophical" isn't quite the right word...eh, something. Not sure what, but definitely something.

Also tbh, I may or may not be slightly biased, due to the CornerRadius/BorderThickness case in particular being so relevant specifically to user-skinnable apps

[maxkatz6]

RadioButtons/GroupedContainer can be useful control that solves some specific problem, but it won't solve another cases like Popup+Border example from another thread. Let's say we have inner and other Borders, where we want to reuse same CornerRadius, but with different Top values and without defining hardcoded values in the resources (which can be fine in developer's applications, but won't be fine in the control libraries). I wrote some my thought in that another thread as well.

[robloo]

In your example, Popup would have a CornerRadius StyledProperty that binds to all elements with a corner radius. The filter converter for corner radius would be used on the inside border that doesn't have rounded corners. I think this could be handled just like WPF/WinUI. Do I misunderstand the concerns?

[maxkatz6]

@robloo you are right, that's what I meant. Converter solves this problem, but it doesn't work well with shared resources, as I described here #5594 (reply in thread) (if we don't have CornerRadius property).
And also Popup probably shouldn't have CornerRadius property anyway, because it's more low-level control that can't map this radius to native components. Although Flyout potentially should have it.

[Sorien]

maybe the whole problem is that Avalonia is missing first-child and last-child selector https://quirksmode.org/css/selectors/firstchild.html

edit:
some css sample https://jsfiddle.net/ghc1v3ye/

[Splitwirez]

Like with @robloo 's second post, this would only solve one specific use case, rather than addressing the actual underlying problem. Still probably a good thing to have though

[robloo]

This is actually a good idea I think. It fits in with the concepts as they stand today as well.

[Splitwirez]

Agreed

[maxkatz6]

I wonder, should these pseudoclasses work with materialized containers for Items or should it detect first/last child from the ItemsLayout/ItemsPanel.
But in any way this feature will benefit in most of use cases.