Enabling Fluent as Default System Theme - Next Steps ?

[dipeshmsft]

In WPF we have two types of styles for any FrameworkElement - Style and ThemeStyle. Style attribute allows developers to provide custom styles for the controls, whereas ThemeStyle provides a default style which will be used in the absence of custom styles provided by the developer or when developers override only a few properties for the control in the custom style. ThemeStyle ( from here on I will refer to them as default style ) is an internal property and developers don't have access to this property. The default styles are loaded by the framework based on the OS version and color scheme.

As of now, Fluent theme can be loaded by including the resource dictionary in App.xaml, which means that the framework treats them as non-default style and they are loaded in Style property for the framework. Ideally we would want to load them as default styles however, there are some constraints to that approach.

Constraints of making Fluent a theme style

• Theme style lookup is different from the lookup of other styles. When a resource dictionary is loaded as default style, we can not search for resources ( like brushes , colors or styles ) which have a key of type string. Theme resource dictionaries are only searched for resources when the key is either a Type or a ResourceKey. This will prevent a developer from using resources defined in Fluent theme dictionary. Essentially, that means, we won't be able to access AccentButtonStyle, ControlElevationBrush, etc. by referencing them in custom style as it is possible in WinUI.

    <!-- These scenarios will be blocked, where AccentButtonStyle and ControlElevationBorderBrush is present in Fluent theme dictionary -->
    <Button Style="{DynamicResoucrce AccentButtonStyle}" />
    <CustomTextBlock BorderBrush="{DynamicResource ControlElevationBorderBrush}" />  

• Theme styles do not support DynamicResource very well. Uptil now, if you had to use DynamicResource in theme style, you would have to use ComponentResourceKey or follow a pattern similar to SystemColors, where we have a set of colors and brushes that can be referenced. This restricts the way in which we can define and use accent colors and brushes. For theme dictionaries when we use DynamicResource, we get back DeferredThemeResourceReference instead of DeferredResourceReference, which gets inflated, frozen and cached.

To deal with the above constraints, we have two options :

• Modify the fluent theme resources and styles to fit in the current system : That would require exposing public API for accent colors. Making some resources static, creating seperate theme files for light and dark mode ( we are on top of this already ).
• Enhance the capabilities of theme resources : Allow searching for resources using string keys. Allowing DynamicResource to work with theme resource in full capacity. ( I have been working on this, but this is more complex than I thought and will require more time and efforts. ). This will also open up the framework for more flexibility, but at the same time make it easier for things to go wrong.

We don't face these issues in the current setup ( i.e. fluent theme resources are loaded in app.xaml ). In the current setup, the styles are treated as implicit styles ( when we don't provide a key for a style or we provide the Type as the key, it get's used for all controls without specifying it everywhere ) and we can search for any resource defined in the resource dictionary. Now, when we use this resource dictionary via app.xaml, DynamicResource works as we all know it.

Although the current setup is temporary, and even if we continue with the current setup in .NET 9, it has it's own disadvantages.

Issues with using Fluent as implicitly loaded style

• Whenever, framework elements are generated via code ( like in DataGrid ) the framework creates the object and does not set the Style property, it relies on ThemeStyle for it's styling. This will cause inconsistent UI in the application. That is the reason why, we had to add checks at some places in code to maintain that consistency in UI. ( Still need some more investigations here )
• It becomes very easy to modify resources. This can lead to different scenarios of using the themes, it makes it easy to remove some particular styles or resources which can again lead to inconsistencies in UI.
• The whole setup depends on the presence of an instance of class Application, which may not be present in some scnarios. As this current theme loading and switching is temporary, and once we move from this model to the default one, we will hit the constraints there. Now, where we can access the resources by string key names, once we make the theme default, won't work anymore until and unless the capabilities of theme resource are increased. However, doing that would would essentially mean that we are treating resource names as public contracts, and would need to deal with performance issues.

Keeping in mind the time frame for .NET 9 and that we are already past preview 6, getting all the features completed is difficult. So, we would like to seek community opinion on what path shall we take for now.

[dipeshmsft]

cc @miloush @batzen @pomianowski @ThomasGoulet73 @lindexi @MichaeIDietrich @robert-abeo @riverar @KirillOsenkov @Symbai

[lindexi]

Given the current time constraints, our development window is rapidly closing. I am inclined to opt for "Modify the fluent theme resources and styles to fit in the current system". My rationale is that it's preferable to choose a fully functional option with minor flaws, rather than a more refined but potentially incomplete solution. There's no perfect balance between functionality and resource allocation. My only concern is that this choice might result in legacy issues, making it difficult to modify the framework behavior in the future.

Currently, my concerns are as follows:

1. The extent of testing on Fluent: I worry that it might necessitate patches immediately after the release of the ".NET9" version.
2. Compatibility issues: This could potentially make it difficult for the project to upgrade from the old framework to the new version.
3. Performance issues: I've noticed that the current styles heavily utilize DynamicResource. As is widely known and as @dipeshmsft pointed out, this could impact software performance. Fortunately, performance isn't a critical issue and can be continuously optimized in subsequent framework versions.

[miloush]

Thanks Dipesh!

First of all, I don't think the Fluent theme should become the default theme. It is designed for different kind of apps (with less information density) than what I expect most developers to be using WPF for, and it could hamper the adoption of newer .NET versions. I am open to be convinced otherwise, but I would think we should have a few releases with the theme shipped and perfected before making it default.

Second, a theme should be a "proper" theme. Having it in App.xaml as merged dictionary (i.e. "implicitly loaded" above) is not how themes should be shipped or used in production. In addition to the issues discussed above, it changes the precedence of resources for dependency properties. However, I understand that not everything is or will be ready in time for .NET 9 and if we want to keep the new theme "for testing" through next release, I am guessing keeping it as is would continue to serve the purpose.

For the technical concerns raised:

• I understand that button (and currently only button) has two styles, one normal and one "accented" and it is up to the developer to select which one to use. This is the only case for which you need to lookup resource by string and "enhance the capabilities of theme resources". I am quite hesitant to support significant theming system redesign just for this case and would be more inclined to fix this "anomaly". Perhaps this can be done using visual states, an attached property, resource key from the theme assembly, separate resource dictionary, or, you know, just not supported in the initial release.
• Accent colors should certainly be available the same way system colors are available, regardless of theming. I would also suggest a review of the theme and getting rid of as much as dynamic resources as possible (simply don't allow such amount of runtime customization).

That makes me support the "Modify the fluent theme resources and styles to fit in the current system" option.

My preference would be:
If there is time:

• Turn the theme into a proper theme assembly, both dark and lights should be in one, following name.color.baml conventions, even if not all aspects of the theme can be accessed or utilized at the moment
• Provide a way to opt in into the theme, preferably by means of switching themes, but a compatibility switch or app.config setting would also work if running out of time.
• Make accent colors and brushes available in system colors/brushes. These should reflect system ones rather than theme ones.

If there is no time, continue having the theme available for testing and debugging purposes "on the side" for .NET 9, but do not ship any API changes in support of it.

[Symbai]

Lets say I have made an app which I have overridden some colors on some controls for some purpose. Then I just recompile it on .NET 9.0 or whatever and suddenly it has this "fluent theme" which then collided with my changes. I don't think this is a good idea. IF you make breaking changes then it should be something worth it. Like WPF now allows AOT, trimming and what not. (and they're on by default) Then I would be okay with making these changes too. Not because they are necessary but because we are already having huge breaking changes that it won't matter anyways. But we don't have them yet. The only thing we have is this fluent theme which, at the time I was testing it, contains issues. It makes no sense to me to make fluent theme a default theme, at this moment! This is not a technical perspective but a rational.

[dipeshmsft]

Before this discussion moves on, when talking in terms of .NET 9, there will be a switch that will allow the framework to load Fluent as the default theme. I know there are issues with styles and Fluent specific style for all controls is not yet present, so there is no question of Fluent being system theme by default.

@miloush @Symbai @lindexi, hope this clears our stand when we are talking about Fluent as default theme.

As mentioned above, there are wide differences in the capabilities of both methods. In the current system, there is flexibility of overriding brushes and colors, referencing default styles and creating custom styles and this will setup a precedence that all of these features will be supported in next versions. However, loading as default ( still opt-in ) currently does not support all this, so moving ahead we will be adding functionalities to the theme rather than subtracting them.

Loading themes implicitly, i.e. adding the fluent dictionary to app.xaml is always present as a choice to developers to support higher level of customizations.

Coming to the API proposals, there are two proposals that we can work on :

• Theme Switching Support ( [API Proposal]: FluentWindows Theme Switch in WPF #8932 )
• AccentColor as SystemColors ( this will be required if we choose to remove the current setup and use Fluent as an opt-in default style )

[robert-abeo]

There is a lot to this discussion:

I was expecting you all to ship this with the current method: implicit styles that we have now registered in the app merged dictionaries overriding the theme styles. That said, I have personally encountered the issue of theme styles being used for programmatically created controls and then design inconsistency as the style is forcefully changed. It's not ideal in this way but seems the lesser of two evils (different for all of your assessments above).

The reason I say this is the lesser of two evils is simply because we MUST have access to the resources in the fluent styles. There are several custom controls that need to use shared resources (by key) in their control themes. Accent button is one example noted above as well. All of the Fluent v2 theme is designed to work this way and all existing code (even in WPF) is setup to use this. We are going to have a really difficult time moving away from other Fluent theme implementations if we loose this capability here. It's probably going to end up meaning we just copy the theme and register it in merged dictionaries ourselves.

As far as dynamic resource usage everywhere, it's required because in modern windows we are expected to be able to dynamically change between light/dark themes. I suppose I would be OK with a mechanism that supports this change only at startup rather than runtime though. Still, ThemeResource in WinUI is looking important right about now.

The concern about Fluent NOT being the default theme I somewhat agree with. Most legacy applications are designed for different information density than modern Windows desktop apps. HOWEVER, we have the compact density styles in WinUI to compensate for this. Hopefully that will be carried over here but I haven't dug into the code in that area.

Personally, like WinUI/Uno/Avalonia, I would expect a way to choose the theme in the application class at startup. In WinUI2 you could switch between Fluentv1/2 as desired and set the density style. Avalonia also allows registering the theme to use in App.xaml and there are a number of themes available even from 3rd parties. WPF locking this all down for theme styles and registering them behind the scenes was a mistake.

There are too many points to address right now but I'm advocating for just using the method we have now:

1. This is best for compatibility with existing Fluent themes (we have to transition slowly from ModernWPF, etc.)
2. This allows using the Fluent theme in older Framework applications (just have to copy/paste some code)
3. We have access to the very important resources by key to use in custom controls and for things like accent button style
4. We can still dynamically switch light/dark/etc at runtime and really do whatever we want by modifying the application-level merged resource dictionaries.
5. We DON'T break any existing apps because behind the scenes we are still loading Aero2 as the theme by default and then just adding on top.

The ONLY downside I see to this is for programmatically generated elements like popups that might retain Aero2 in some cases. But I consider that the lesser of two evils until the WPF theme system is upgraded to support what we need here (as discussed in the original description). My assumption is we can move to a more integrated design in the future with minimal breaking changes.

[miloush]

we MUST have access to the resources in the fluent styles. There are several custom controls that need to use shared resources (by key) in their control themes.

Can you give some examples beside the accented button?

As far as dynamic resource usage everywhere, it's required because in modern windows we are expected to be able to dynamically change between light/dark themes.

You don't need dynamic resources for that, just two versions of the theme.

[robert-abeo]

Can you give some examples beside the accented button?

No, I can't share specific code examples. But think of it this way: If you are writing a ColorPicker or other custom control you need to have access to the underlying Fluent theme resources. These resources are consumed by all custom controls to implement their themes that match Fluent. If you are using nothing but stock controls, sure, you can let it all be hidden away. But as soon as you start extending things you need access to the keyed resources. (Please don't recommend duplicated code here too).

Edit: Another few cases in an existing app: accent colors need to be customized (user has some ability to adjust themes) and certain in-box control themes are customized too. If you can't have access to the underlying resources (think colors, brushes, etc.) this is a lot more difficult.

You don't need dynamic resources for that, just two versions of the theme.

That's a lot of duplicated code that is definitely worse in my book that using dynamic resources. If the two themes could be GENERATED from what we have now I would be OK with it. But we are well past the point in time where it makes sense to duplicate code like this.

[miloush]

I meant examples of resources you think need to be accessible.

If you are writing a ColorPicker or other custom control you need to have access to the underlying Fluent theme resources.

Which ones?

We have had the current system for years spanning several themes, so it's not like new limitations are being introduced. If you are lacking features, it would be useful to keep track of them.

If the two themes could be GENERATED from what we have now I would be OK with it.

Sure, that's how it has been for decades now.

wpf/src/Microsoft.DotNet.Wpf/src/Themes/XAML/GroupBox.xaml

Lines 97 to 138 in 6d26b95

	<!--[[Luna.Homestead]] -->
	<SolidColorBrush x:Key="GroupBoxBorderBrush"
	Color="#D0D0BF"/>
	<SolidColorBrush x:Key="GroupBoxHeaderBrush"
	Color="#99540A"/>
	<!--[[Luna.Metallic]] -->
	<SolidColorBrush x:Key="GroupBoxBorderBrush"
	Color="#BFB8BF"/>
	<SolidColorBrush x:Key="GroupBoxHeaderBrush"
	Color="#0046D5"/>
	<!--[[Luna.NormalColor]] -->
	<SolidColorBrush x:Key="GroupBoxBorderBrush"
	Color="#D0D0BF"/>
	<SolidColorBrush x:Key="GroupBoxHeaderBrush"
	Color="#0046D5"/>
	<!--[[Royale.NormalColor]] -->
	<SolidColorBrush x:Key="GroupBoxBorderBrush"
	Color="#D6D5D9"/>
	<SolidColorBrush x:Key="GroupBoxHeaderBrush"
	Color="#335EA8"/>
	<!--[[Luna.Homestead, Luna.Metallic, Luna.NormalColor, Royale.NormalColor]] -->
	<!--=================================================================
	GroupBox
	==================================================================-->
	<BorderGapMaskConverter x:Key="BorderGapMaskConverter"/>
	<Style x:Key="{x:Type GroupBox}"
	TargetType="{x:Type GroupBox}">
	<Setter Property="BorderBrush"
	Value="{StaticResource GroupBoxBorderBrush}"/>

[robert-abeo]

@miloush You misunderstand my viewpoint. I have used the existing Fluent v1/v2 themes in UWP/WinUI and am currently using a customized version of ModernWPF that supports Fluentv2. What I am referring to are features that are expected in modern Fluent themes. I'm not referring to features that are in legacy WPF. So when you say "We have had the current system for years spanning several themes" that's true BUT we have all moved past that with third party libraries now.

For example, all Fluent2 themes for WPF (third party) have used the dynamic resource approach or some variant that allows switching between light/dark WITHOUT duplicating the entire theme and customizing it for light or dark. What I'm saying is the ecosystem has evolved quite a bit here and the expectations are now different than what was in Aero2. If you take a lot of that functionality away we simply will not be able to use the Fluent2 theme in WPF and will continue using third-party implementations that have the expected functionality. I'm trying to make it possible and more streamlined for those applications that are already using a third-party Fluent2 theme to be able to migrate to the official one here.

I'm not going to invest the time digging up all the Fluent2 resource keys we use in custom controls right now. I think I was clear in why it's important to be able to access resources by key:

1. Custom controls that need to implement Fluent styles themselves need access to the underlying colors/brushes
2. Modification of in-box control theme styles (using the same resources where needed)
3. Theme modifications to the existing Fluent that change the accent color based on user settings (this means need to change the accent colors dynamically). This is actually more complex than just accent color though, a custom "blue" theme (like in Office) is needed where the backgrounds are changed to blue. That involves overriding a number of background brushes by key and is possible with all 3rd party Fluent themes right now but as I understand it WOULD NOT be possible with a system theme style.

[miloush]

I believe 2. was explicitly stated as undesirable. For 3., the colors and brushes in SystemColors can be overridden, it's only string keys that cannot be looked up. Basically there needs to be a contract between themes and the framework of known resources. To extend the current contract, you need to know which ones are missing for 1.

I'm not going to invest the time digging up all the Fluent2 resource keys we use in custom controls right now.

That makes it difficult to argue a point, I am sure your experiences would be valuable. There is no need to list them all. If you can find a few, especially referencing a Style like in the case of accented button, it would be helpful.

I'm trying to make it possible and more streamlined for those applications that are already using a third-party Fluent2 theme to be able to migrate to the official one here

I don't remember that being a goal at any point. People are also free to continue using whatever works for them.

What I'm trying to avoid is 1) having two completely separate, incompatible theme systems 2) unnecessary development and maintenance of something that will be obsoleted with next theme 3) significant performance degradation.

[batzen]

@miloush

1. You can't use the keys from theme resources as they are mangled.
2. As i said when the Fluent efforts started: WPF now has to compete with decades worth of development of third party libraries. If it's in no way customizable people won't use it. Not even i would use it if I could just use a much more flexible third party solution.
3. Have you measured that? Especially when using a WPF version with my DynamicResource PR?

[dipeshmsft]

@batzen

You can't use the keys from theme resources as they are mangled.

Mangling is something that we can control,, earlier it was done for optimization and because developers did not have access to the string based key resources. So, not mangling but being able to find string based key resources in theme style resources is the issue.

Have you measured that? Especially when using a WPF version with my DynamicResource PR?

We haven't tried this yet.

@robert-abeo

2. unnecessary development and maintenance of something that will be obsoleted with next theme

Regarding the point @miloush said, although loading in app.xaml gives us a great amount of flexibility and even if we continue with the same model, I don't think that is the right places as it disables the scenarios where Application instance may not be present. It would have to be in a more neutral location.

That's a lot of duplicated code that is definitely worse in my book that using dynamic resources. If the two themes could be GENERATED from what we have now I would be OK with it. But we are well past the point in time where it makes sense to duplicate code like this.

For this, I have written a script to combine the resource dictionaries into one, similar to the ThemeGenerator that we have for earlier themes. I will put it up by the end of the week.