Add Control.ActualWidthProperty and Control.ActualHeightProperty

[comesx4]

What does the pull request do?

Add Control.ActualWidth and Control.ActualHeight property.

What is the current behavior?

We can get the control's actual width and height from Bounds property, But the existing WPF coders are familiar to ActualWidth and ActualHeight property.

What is the updated/expected behavior with this PR?

Add Control.ActualWidth and Control.ActualHeight which are the equivalent to WPF's FrameworkElement.ActualWidth and ActualHeight.

How was the solution implemented (if it's not obvious)?

Inspired by #9307 , simply add two DirectProperty on Control and return value form Bounds.
Raise property changed in SizeChangedEvent.

Checklist

- [ ] Added unit tests (if possible)?

• Added XML documentation to any related classes?

- [ ] Consider submitting a PR to https://github.com/AvaloniaUI/Documentation with user documentation

Breaking changes

None

Obsoletions / Deprecations

None

Fixed issues

None

[dnfadmin]

All CLA requirements met.

[avaloniaui-team]

You can test this PR using the following package version. 11.0.999-cibuild0025696-beta. (feed url: https://nuget.avaloniaui.net/repository/avalonia-all/index.json) [PRBUILDID]

[robloo]

I very briefly thought about this with size changed. However. I didnt want to complicate the API for little reason. Working with an observable on the Bounds property vs. SizeChanged event was problematic for a few reasons so it seems to be a clear missing feature.

However, ActualHeight and ActualWidth is not filling the gaps in a missing feature. It is duplicating API for compatibility. Generally, I think the decision to do this should be very rare and in this case doesn't meet the threshold. It's ridiculously easy to change code over to using .Bounds.Width instead of .ActualWidth. An actual find and replace can do it with no issue. Again, the same isn't true for SizeChanged which is a slight feature enhancement and allows compatibility with different code patterns (not something find replace can fix).

So while this is good for compatibility I'm not actually in favor of this PR. I think we should fill gaps is functionality but not try for perfect compatibility with WPF.

Besides, Avalonia seems to be the only real future for Xaml frameworks and I've found its better just to do a clean break rather than trying to maintain WinUI or WPF alongside Avalonia sources.

[maxkatz6]

I agree with @robloo here. It was possible to replace SizeChanged with subscribing on a property changed. But it was adding quite some unnecessary code for the very common task. Not to mention it wasn't intuitive and many developers were thinking this possibility is just missing.
While with ActualWidth/Bounds.Width we indeed have a different naming here, but it doesn't require user to write more unintuitive code.

So, I am going to close it now. Thanks @comesx4 for the interest in contributing!

[comesx4]

Fine, that's ok.