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
24.62k stars 2.13k forks source link

Implement Fluent v2 theme #6269

Open maxkatz6 opened 2 years ago

maxkatz6 commented 2 years ago

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:

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:

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".

PieroCastillo commented 2 years ago

very well, but, how are you going to add this? https://docs.microsoft.com/en-us/windows/apps/design/layout/depth-shadow

maxkatz6 commented 2 years ago

@PieroCastillo BoxShadows?

robloo commented 2 years ago

Few initial comments, I'll add more later:

If Fluent theme is staying in Avalonia repo I think it should always attempt to be latest and drop older styles. It is very common in UI frameworks to completely update styles periodically and force apps to update as well if they want to use the new framework version. As annoying as this is, literally everyone does it to try to enforce uniformity which is important for end users.

If fluent will be pulled out in separate nuget we might as well support both fluent v1 and v2 and leave it up to app developers. However, I would only do this if macOS, Android, etc. will get their own styles going forward too. I know the team doesn't want to take up maintenance of all this, but it will be extremely useful long term for some apps who heavily customize per platform. It will also make Avalonia itself more competitive.

maxkatz6 commented 2 years ago

If Fluent theme is staying in Avalonia repo I think it should always attempt to be latest and drop older styles

I don't think anybody planned to move Fluent theme out of the main repo.

amwx commented 2 years ago

The biggest changes with the v2 styles are:

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):

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.

nlogozzo commented 2 years ago

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

robloo commented 2 years ago

@amwx Is awesome! I do hope the FontIcons, NavigationView, updated themes, etc find their way into Avalonia itself. This has been discussed but not with the core maintainers afaik.

nlogozzo commented 2 years ago

@maxkatz6 Should be something to consider, @amwx has already put in most of the work for getting the styles and many controls already ported and working beautifully!

amwx commented 2 years ago

@amwx Is awesome! I do hope the FontIcons, NavigationView, updated themes, etc find their way into Avalonia itself. This has been discussed but not with the core maintainers afaik.

We had a discussion about the NavigationView a couple months ago. Not much movement on that since though b/c I've been working on some other things and there's a few things I'd like to clean up/fix with it before (and if) it gets moved (like supporting multiple datatemplates, which is what I'm trying to work out now). @maxkatz6 is working on Icons and his approach is probably better for the core repo since it's more flexible.

Back on topic, the updated themes are there for anybody to do whatever with. Should be mostly copy and paste, except where I've replaced Paths with my Symbol/Font icons for the Fluent icons - but somewhere iirc we have an exported version of the svg path data for all the fluent icons, so that should be a simple fix. There are some controls that I haven't brought into the new styles either b/c they're lookless/don't depend on Fluent theme or I've added a replacement (e.g., I ported NumberBox to replace NumericUpDown), but it shouldn't be terribly difficult to add those.

Tryanks commented 1 year ago

Hi, any progress on this proposal? I love Avalonia and I'm also the biggest fan of Fluent Design. Now I'm using FluentAvalonia theme and I'm looking forward to the day when it will be merged into the official implementation, or the official implementation of Fluent v2 itself.

maxkatz6 commented 1 year ago

@Tryanks please continue to use FluentAvalonia if you need Microsoft Fluent v2. There are no plans to port it to the main framework. If anything, we could have a unique theme based on fluent, but adapted to the macOS styling slightly.

robloo commented 1 year ago

Personally, I think it's a good idea to modernize again with Fluent v2. Keeping Avalonia updated to latest design trends out of the box is important.

Additionally, Fluent v2 doesn't look out of place on most platforms including macOS and web.

Fluent v2 only needs a few tweaks to margins/padding that assume certain Windows-specific font sizes to work decently on macOS.

heartacker commented 9 months ago

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

good idea

robloo commented 8 months ago

It might be a good time to implement this one now:

@amwx @workgroupengineering Any thoughts on this?

This is something I would be willing to start working on myself. No promises on timing. It would just be a new themes package probably with the Fluent2 name.

timunie commented 8 months ago

@robloo it has not been decided how we want to proceed here. So before you start working on it, please ask for a short confirmation. I don't want anyone doing work twice.

workgroupengineering commented 8 months ago

It might be a good time to implement this one now:

* WinUI 3 is now open source (at least as a branch in the WinUI repo). This means all the previously missing Fluent v2 styles should exist (before several of them had to be guessed).

* FluentAvalonia is on pause. Pulling in Fluent v2 control themes into main Avalonia for the core controls would actually help that project most likely as only new controls would be needed.

* Fluent v2 styles look even better cross-platform. I know TextBox and others wanted to be updated to get the underlines for mobile platforms.

@amwx @workgroupengineering Any thoughts on this?

This is something I would be willing to start working on myself. No promises on timing. It would just be a new themes package probably with the Fluent2 name.

I think it's a good idea, there are some necessary controls like NavigationView. I can give you a hand when I have some spare time. In my opinion it should be implemented in the Avalonia.Labs repository.

Before investing time, however, you need to understand:

We could start by creating a pool to see what the priorities are.

robloo commented 8 months ago

@timunie

it has not been decided how we want to proceed here. So before you start working on it, please ask for a short confirmation. I don't want anyone doing work twice.

Yes, I'm aware and won't start unless the core team is on board. I am merely restarting the discussion about this and willing to do some of the heavy lifting. I also know you might have some other ideas on how you want to address themes going forward. This isn't something I would pick up in the next few months so there is time for more discussion.

@workgroupengineering

I think it's a good idea, there are some necessary controls like NavigationView.

For clarification I am NOT talking about merging in FluentAvalonia or pulling in any new controls with this. This issue and my goal is ONLY to create Fluent v2 styles for Avalonia's in-box controls. FluentAvalonia will still be needed to provide new controls from WinUI not already in Avalonia and the Fluent v2 styles for them.

what are the implementation times of the Target in the setter https://github.com/AvaloniaUI/Avalonia/issues/11537

Yes, that would help a lot especially to keep control themes more similar to upstream but is not actually required.

I don't think the other points on your list other than core team opinions are critical. FluentAvalonia has already proven there are no roadblocks. Fluent v1 was already ported to Avalonia as well.

workgroupengineering commented 8 months ago

I don't think the other points on your list other than core team opinions are critical. FluentAvalonia has already proven there are no roadblocks. Fluent v1 was already ported to Avalonia as well.

Yes, there are actually points with lower priority.

  • if the Avalonia Team has scheduled changes in the management of the Themes in its roadmap

In my opinion, this point is very important, because some changes could nullify the work.

Before starting the work we need to refactor the priority of how the styles are applied.