Implement Fluent v2 theme

Is your feature request related to a problem? Please describe

With Avalonia 0.10.0 we implemented Fluent theme, which was based on Windows 10 and WinUI 2.5 styles. In 2021 we can see, that Microsoft revisited their default system theme in Windows 11 and build Fluent v2 styles in WinUI 3 (also backported to WinUI 2.6). Which means that Avalonia has out-of-dated themes comparing with Windows OS.

Open questions

Do we need to update Fluent theme at first place?

It’s a good question, because Avalonia is cross platform framework, that works not only on Windows OS. So why its build-in styles should always follow only single target platform styles? On other hand, as a maintainers team we can’t support default themes for each platform (luckily, community already created some of them). Also, worth to mention that Fluent v2 is closer to macOS styles than Fluent v1 was. And Linux never had single standard theme to follow. Realistically we can chouse one of two ways:

• Keep Fluent v1 theme, it’s good as it is.
• Update Fluent theme to match Win11.
• Find designer, who will build new theme styles, based on Fluent v1, but with macOS components as well to be more universal.

How did Microsoft deliver new theme to the developers and what happen with old one?

They support both of them. WinUI and Avalonia allow developers to build custom styles on top of build-in ones, which results in non-possibility to make any huge changes, that will be considered as a breaking change. And Fluent v2 has a lot changes of that kind. To deal with it, Microsoft introduced Fluent theme versioning, having style files and resources for both versions, keeping them side by side in a single repo, allowing users to switch theme version on app top level:

<XamlControlsResources ControlsResourcesVersion="Version2" />

How Avalonia should deliver new theme to the developers?

This question is more to the community. There are several possible ways, that I see right now:

• Follow Microsoft’s way, keep both versions together and add top level switcher. Unfortunately, it will cause significantly higher maintenance cost.
• Do breaking change. If developers need time to update their styles, they should continue to use previous Avalonia version (with backport fixes for a while).
• Do breaking change (in a bit more controlled way):
• • In next major release (later this year) move Fluent (and old Default) theme out of Avalonia main package (see https://github.com/AvaloniaUI/Avalonia/issues/5593). It will break all existing applications, but fix will be easy as just adding missing nuget package (we can do a check with warning to inform developers in runtime about that).
• • In next major release (next year) update Fluent theme package doing all required changed to bring new theme to life. It will allow developers either to stay on older Fluent package version for a while, giving them time to update their custom styles.

Since we still might consider moving themes out of Avalonia main package, last approach seems to be most convenient for maintainers (and not that much for developers, who will use it).

Is it really that important breaking change? Can’t we just update it?

Good question. Personally, I built couple of applications with custom styles on top of Fluent theme. And while for me it won’t be a problem at all to do required changes (since I am familiar with this repo), I can’t say the same about everybody.

Additional context

For examples and details see “Design in Windows 11”.

[nlogozzo]

This hidden gem has actually started some of this work: https://github.com/amwx/FluentAvalonia I suggest you contact the developer and merge that library with main Avalonia

[amwx]

The biggest changes with the v2 styles are:

• Renaming of the base colors/brushes. IMO the new names make more sense, and it’s only an issue if you’re directly referencing a brush/color intead of a StaticResource alias like ButtonBackground
• The corner radii were doubled 2->4 for controls and 4->8 for overlays (Popups)
• Margins and paddings in some controls were adjusted to work with the new design, but I don’t think these are super breaking

Most of the work is done just by switching out the brush and control resources, and making a few small adjustments to some of the templates. Text controls and buttons needed a template adjustment to separate the border element from the rest of the control to cope with the inverted border brush (which as I said before, won’t be needed if transforms can be added to brushes in the future). There were some API changes added in a couple controls, but I think they don’t really affect Avalonia, or at least can be worked around.

IMO, I think v2 looks miles better than v1, so I’m for fully replacing it - and I think targeting the next major release would be ideal. I assume that will probably come around or after Win11 release and MS should be done tinkering with the theme by that point.

I think one thing that might help maintenance should v1 remain (either with versioning or as a deprecated theme), is if some updates to the styling system could be added. Right now, templates are quite cluttered and can be large and it makes it hard to follow and port things sometimes. Personally I’d target 3 things (these are nothing new, other issues have suggested these):

• Fix the local value/binding issue inside templates not being overridable
• Default Style keys
• Allow grouping based on classes and/or add a Target Name to setters so each individual control that needs to respond to the change doesn’t need it’s own <Style> declaration. For Example, in Avalonia, checkbox :pointerover requires 4 separate <Style>s https://github.com/AvaloniaUI/Avalonia/blob/898ed78437cac387e56b15d147da43cf9089aec4/src/Avalonia.Themes.Fluent/Controls/CheckBox.xaml#L82-L98

Where as WPF/WinUI that would be condensed in the VisualStateManager if you remove the whole storyboard/keyframe thing the VSM uses: (not arguing for a VSM, but just comparing the verbosity):

<Setter Target="ContentPresenter.Foreground" Value="..." />
<Setter Target="PART_Border.Background Value="..." />
etc...

This would probably be a breaking change? but would help clean up control templates, and probably make porting things over from WinUI a lot easier. I’m just thinking aloud, but that’s my thoughts.