Initial support for WinUI 2.6 styles

[MartinZikmund]

GitHub Issue (If applicable): #

PR Type

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• Docs have been added/updated which fit documentation template (for bug fixes / features)
• Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• Validated PR Screenshots Compare Test Run results.
• Contains NO breaking changes
• Associated with an issue (GitHub or internal) and uses the automatic close keywords.
• Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

[gitpod-io]

[robloo]

Awesome! Looks like a lot of work.

Could you add a little documentation when you have a chance on how this works? I was wondering how you would be implementing it. I was also never 100% sure how all XAML locations work together: XAML in controls folders, XAML in FluentTheme, all the FluentTheme priority folders, etc.

When porting controls from WinUI library it looks like the XAML generator will work with the original files as-is. Any v1 suffixes will be used for version 1, any files without suffixes will be assumed as the max version (currently 2). So when porting controls like the ColorPicker I can just copy/paste the files no issue.

[MartinZikmund]

@robloo you are right, it is probably quite worth documenting 👍 . In short however, the main point of the "Priority" folders is to ensure the files are merged in a order that ensures that the styles that are referenced by other styles occur earlier in the merged file. For example Priority01 contains Common_themeresources as they are referenced almost everywhere. Then AcrylicBrush_themeresources are in Priority02 because they reference things from 01 but are themselves references by things in PriorityDefault for example.

[jeromelaban]

It's likely that we'll need to update the fluent font to match newer glyphs (like DropDownButton)

[davidjohnoliver]

@robloo you are right, it is probably quite worth documenting 👍 . In short however, the main point of the "Priority" folders is to ensure the files are merged in a order that ensures that the styles that are referenced by other styles occur earlier in the merged file. For example Priority01 contains Common_themeresources as they are referenced almost everywhere. Then AcrylicBrush_themeresources are in Priority02 because they reference things from 01 but are themselves references by things in PriorityDefault for example.

No :D This isn't necessary, XAML supports lexically forward references.

The FluentTheme XAML resources are placed into Priority files according to the value of the Priority attribute in the WinUI repo's project structure. Eg:

https://github.com/microsoft/microsoft-ui-xaml/blob/9052972906c8a0a1b6cb5d5c61b27d6d27cd7f11/dev/Materials/Reveal/RevealBrush.vcxitems#L32-L37

The WinUI repo uses the 'Priority' attribute to determine which resource 'wins' in the case of duplicate resource declarations. So in the case that, say, two different XAML files declare a SplartControlForegroundBrush resource, or a default ListViewItem style, the one with higher priority is the one that actually gets included in the amalgamated themeresources.xaml file. That's done here:

https://github.com/microsoft/microsoft-ui-xaml/blob/bbc4549d65222be8fc9deb128afabb624ae191e9/dev/dll/Microsoft.UI.Xaml.vcxproj#L648-L656

We could probably duplicate in detail what the project system is doing, but to save time I used the trick of just putting them in different folders, which achieves the same thing based on the order in which Uno's XAML generation processes files.

This hopefully partially answers the question @robloo posed in #6926 . :)

GitHub

microsoft-ui-xaml/RevealBrush.vcxitems at 9052972906c8a0a1b6cb5d5c61b27d6d27cd7f11 · microsoft/microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications - microsoft-ui-xaml/RevealBrush.vcxitems at 9052972906c8a0a1b6cb5d5c61b27d6d27cd7f11 · microsoft/mi...

GitHub

microsoft-ui-xaml/Microsoft.UI.Xaml.vcxproj at bbc4549d65222be8fc9deb128afabb624ae191e9 · microsoft/microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications - microsoft-ui-xaml/Microsoft.UI.Xaml.vcxproj at bbc4549d65222be8fc9deb128afabb624ae191e9 · microso...

[davidjohnoliver]

I haven't looked through every line of the imported v2 resources... but I wonder, did you do a search for 'Uno' in the existing v1 resources, and reapply any Uno workarounds to the new resources?

If you haven't done that yet, it might make sense to merge this PR first and then do that, but it should definitely be done.

[MartinZikmund]

@davidjohnoliver Yes, those Uno specifics have been already applied. What's missing are only the LGB border workarounds

[robloo]

@davidjohnoliver Thanks for the info. I'll quote this in the discussion so its all together for eventual documentation :)

@MartinZikmund These files use the same symbol font Unicode points as upstream, correct? I'm going to pull out all the the WinUI glyphs this weekend and hopefully get an initial mapping to the Fluent UI System. Assuming there are no roadblocks rebuilding the Uno symbol font for WinUI 2.6 styles should be relatively quick -- once the mapping is complete.

[jeromelaban]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).