Fixed theme variant properties

[jp2masa]

What does the pull request do?

Fixed theme variant properties: the names were wrong and the CLR properties have to be in the same class as the Avalonia property (also, changing the property owner doesn't seem to make any difference).

What is the current behavior?

It's impossible to bind to TopLevel.RequestedThemeVariant.

What is the updated/expected behavior with this PR?

It's possible to bind to TopLevel.RequestedThemeVariant. However, it's also possible to bind to any StyledElement.RequestedThemeVariant, so ThemeVariantScope seems to be useless (still testing things, not sure).

EDIT: Setting RequestedThemeVariant on controls works fine, so ThemeVariantScope actually doesn't seem to be needed.

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

Moved the CLR property definition to StyledElement, where the Avalonia property is declared.

An alternative would be to remove the Avalonia property in StyledElement and make the one in TopLevel an AddOwner of the one in ThemeVariantScope.

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

Fixed issues

Fixes #10309

[avaloniaui-team]

You can test this PR using the following package version. 11.0.999-cibuild0029883-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

[amwx]

From my understanding, ThemeVariantScope and the lack of RequestedThemeVariant on all controls is because Avalonia has inheriting properties where UWP doesn't which may cause issues in contexts where a control is using an inherited property (e.g. Foreground)

From theme dictionary PR:

Each control has two properties: RequestedThemeVariant and ActualThemeVariant. RequestedThemeVariant is only accessible for Application, TopLevel (including Window), and ThemeVariantScrope controls. Potentially it can be added to the Page control to improve mobile support. We need this restriction because Avalonia has inheritable properties, while UWP does not. This would cause problems with font and background colors inherited from the parent which has different theme variant. While ThemeVariantScrope override most common inheritable properties.

[jp2masa]

RequestedThemeVariant actually exists on all controls as an Avalonia property. The CLR properties in TopLevel and ThemeVariantScope were simply getters/setters for that Avalonia property which were broken, i.e. binding from XAML didn't work.

As I suggested, it can also be moved to ThemeVariantScope and TopLevel would AddOwner, removing the one in StyledElement (so it couldn't be set on all controls).

There is also the option to "fix" the XAML compiler if this is actually a bug, allowing to have CLR properties in inherited types, but then the Avalonia property in the base class doesn't make much sense I guess?

[maxkatz6]

As I suggested, it can also be moved to ThemeVariantScope and TopLevel would AddOwner, removing the one in StyledElement (so it couldn't be set on all controls).

Yes, I did that in this PR #10149

[jp2masa]

Yes, I did that in this PR #10149

Thanks, I missed that, I'll close this then.