AvaloniaUI / Avalonia

Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The most popular .NET UI client technology
https://avaloniaui.net
MIT License
26.09k stars 2.26k forks source link

Proxy or Calculated Property #11180

Open robloo opened 1 year ago

robloo commented 1 year ago

Is your feature request related to a problem? Please describe.

Shortcoming have been discovered in the property system related to dependent properties and properties calculated from others. These same deficiencies existed in WPF so this is nothing new. However, there is an opportunity to solve this better in the future.

Describe the solution you'd like

  1. Properties that should change and raise property changed events together.
    • First noted here by @grokys where SelectedItem and SelectedIndex, if styled properties, have some synchronization issues.
    • This was apparent after the switch from DirectProperty to StyledProperty. With DirectProperty full control is given in this case to raise events together after both properties are internally handled.
  2. Properties that alias other properties (proxy)
    • This came up in the past to basically support some properties for compatibility with WPF that just alias existing properties with a new type and/or name.
      • This includes properties that are calculated directly from another
      • For example WPF/WinUI's Visibility property could be an alias of IsVisible.
      • Another example is WPF/WinUI's ActualHeight and ActualWidth property could be an alias of Bounds. #11325
    • Another use-case that was discussed in the past is to allow us to fix API mistakes while keeping compatibility. Currently it is very difficult to rename a Styled/DirectProperty. With such a mechanism we can rename a property then keep an old, obsolete proxy/alias property (with the original name/type) around for compatibility until the next major version.
    • https://github.com/AvaloniaUI/Avalonia/pull/6836#pullrequestreview-797475570. "I guess BorderBrush and BorderThickness could be "aliases" for BorderPen.Brush and BorderPen.Thickness but that might raise complications?"

Describe alternatives you've considered

None, these are issues that haven't been solved in WPF or WinUI and weren't fully solved with DirectProperty either.

Additional context Add any other context or screenshots about the feature request here.

maxkatz6 commented 1 year ago

I would also add an inherited readonly properties support. Or, readonly styled properties. Use case - ActualThemeVariant, which right now implemented as an inherited property, and technically can be changed by the user (using SetValue directly).

It alternatively can be a computed property as well. But it would require adding some inheritance functionality to the same.

rabbitism commented 1 year ago

I would support the first idea, but against WPF compatibility consideration. There should be less ambiguity in API design.

robloo commented 1 year ago

@rabbitism, The WPF compatibility considerations were an example. There may be other use cases for this concept.

That said, avoiding ambiguity and duplication is important so I see your point there.

maxkatz6 commented 1 year ago

In general, I agree with @rabbitism and right now WPF compatibility is less important when we have XPF for project that need highest level of compatibility.

Adding Visibility and ActualHeight/Width make less sense now. Possibly as attached proxy properties from a special compatibility project, but this would be quite tricky to do I suppose.

robloo commented 1 year ago

I remembered the other reason for proxy properties that was discussed in the past. It allows us to fix API mistakes while keeping compatibility. Currently it is very difficult to rename a Styled/DirectProperty. With such a mechanism we can rename a property then keep an old, obsolete proxy/alias property (with the original name/type) around for compatibility until the next major version.