Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy or Calculated Property #11180

Open
robloo opened this issue Apr 29, 2023 · 5 comments
Open

Proxy or Calculated Property #11180

robloo opened this issue Apr 29, 2023 · 5 comments

Comments

@robloo
Copy link
Contributor

robloo commented Apr 29, 2023

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. Support at ActualWidth and ActualHeight  #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.
    • Border StrokeDashArray #6836 (review). "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
Copy link
Member

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
Copy link
Contributor

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

@robloo
Copy link
Contributor Author

robloo commented May 11, 2023

@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
Copy link
Member

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
Copy link
Contributor Author

robloo commented May 13, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants