Update all relevant WinUI 2.5 revs to 2.6

[Rosuavio]

Fixes #4085

Update to winui 2.6

PR Type

What kind of change does this PR introduce?

What is the current behavior?

Every project that uses winui uses version 2.5.0

What is the new behavior?

Every project that uses winui uses version 2.6.0

PR Checklist

Please check if your PR fulfills the following requirements:

• Tested code with current supported SDKs
• Pull Request has been submitted to the documentation repository instructions. Link:
• Sample in sample app has been added / updated (for bug fixes / features)
  • Icon has been created (if new sample) following the Thumbnail Style Guide and templates
• New major technical changes in the toolkit have or will be added to the Wiki e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
• Tests for the changes have been added (for bug fixes / features) (if applicable)
• Header has been added to all new source files (run build/UpdateHeaders.bat)
• Contains NO breaking changes

Other information

[ghost]

Thanks RosarioPulella for opening a Pull Request! The reviewers will test the PR and highlight if there is any conflict or changes required. If the PR is approved we will proceed to merge the pull request 🙌

[michael-hawker]

Thanks @RosarioPulella, how does it look at first glance?

[Rosuavio]

It all seems good for a fairly simple change so far. Still investigating if there is anything else that needs to change.

[Rosuavio]

There are some differences in the look and feels of a few things. It might be worth making a script or tool to open a bunch of set configurations of controls and take simple screen shots. It might not be necessary to run on CI at all, but at least it could make it easy to quickly check for visual issues.

For now I am just going to investigate as much as I can on the differences.

[michael-hawker]

There are some differences in the look and feels of a few things. It might be worth making a script or tool to open a bunch of set configurations of controls and take simple screen shots. It might not be necessary to run on CI at all, but at least it could make it easy to quickly check for visual issues.

That's a good idea. It's certainly hard to automate visual comparisons (and brittle). But at least having a script to output visuals could be handy. I think ideally just loading our sample pages in the UI test apps could be handy. Some of these things are probably things we should think of for the future of infrastructure as we move forwards, as not sure how easy it is to integrate into what we have currently.

Want to at least create an issue to track the screenshot idea?

[Rosuavio]

Made the issue. Maybe we should have a project or tag for our major plans for changing the WCT from a high level, be it infrastructure or otherwise?

[Rosuavio]

From going threw the sample app I found a few issues.

• Adaptive grid view
  • Under multi select the when the checkboxes are unchecked they are grayish and they were black, it looks worse.
• BladeView
  • The buttons in the sample blended in with the blade they were on (Dark or light theme)
  • The buttons and the icons of the headers of the blades looks wired/ off center
• TileControl
  • Parallax example does not show tiles at all.
• Infinite Canvas
  • Cant draw with the mouse at all. Might be more issues.
• TabbedCommandBar
  • Some icons for buttons are off center or messed up.
  • Some controls in the bar don't look vertically aligned or they are way too close to the bottom of the bar.

[michael-hawker]

Thanks @RosarioPulella, I know for TabbedCommandBar there's stuff we should fix anyway, tracked by issue #4085.

[XAML-Knight]

Further issues encountered when testing this WinUI 2.6 build:

• XAML code sample sections are not responding to either mouse or keyboard input
• TokenizingTextBox - a token's close button icon is scaled down much smaller than expected
• Expander - radio toggle button foreground ,when On, is black rather than expected light/white color

[Rosuavio]

* Expander - radio toggle button foreground ,when On, is black rather than expected light/white color

I think its behaving the same as main. Maybe I missed the difference, but I don't think this sample changed due to the winui bump.

[XAML-Knight]

* Expander - radio toggle button foreground ,when On, is black rather than expected light/white color

I think its behaving the same as main. Maybe I missed the difference, but I don't think this sample changed due to the winui bump.

No, there's a difference:

[Rosuavio]

I am starting to think that we might want to simply accept the changes we noticed with the AdaptiveGridView. The changes are rather simple and not very impactful changes and it should not break anyone's work flow. The change is because the control inherits from GridView and the styling for selected items on mutli select changed. I don't think it would be worth to override that style and have AdaptiveGridView not match GridView in projects that use the WCT.

It might be a similar case for the Expander. Maybe the black foreground was a very intentional decision from the winui team and our control matches others with that background. Or we are using the wrong key for a foreground style and it should be white still. I am still investigating but I think its important to consider that somethings changing might be best. I do have to say the white foreground looks a lot better.

[michael-hawker]

I think it's safe to assume the WebView issues are due to this bug in WinUI: microsoft/microsoft-ui-xaml#5299 - I'll follow-up with their team.

[Rosuavio]

Infinite Canvas

* Cant draw with the mouse at all. Might be more issues.

When the EnableTouchInkingButton button is clicked it does trigger the code to switch the infinite canvas to mouse mode. The button gets toggled but we can't see it and for some reason clicking on the canvas does not show any marks despite the value of _inkCanvas.InkPresenter.InputDeviceTypes actually being CoreInputDeviceTypes.Mouse | CoreInputDeviceTypes.Pen | CoreInputDeviceTypes.Touch

In a separate app the button's visuals did not seem to update but I was able to draw on the infinite canvas with the mouse.

Edit: In winui 2.6 I noticed that styles were added for some InkToolbar controls including InkToolbarCustomToggleButton which is the type for the EnableTouchInkingButton button.

[michael-hawker]

@RosarioPulella can you add a new sub-element to our NavigationView with the following resource? Looks like we found an initial work-around.

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/1973504661ad0a6152b67deb9896f35103cdae44/Microsoft.Toolkit.Uwp.SampleApp/Shell.xaml#L31-L37

    <winui:NavigationView.Resources>
        <CornerRadius x:Key="NavigationViewContentGridCornerRadius">0,0,0,0</CornerRadius>
    </winui:NavigationView.Resources>

Then that should hopefully fix the WebView and Inking issues?

[Rosuavio]

Then that should hopefully fix the WebView and Inking issues?

WebView - fixed
Inking - fixed

[michael-hawker]

Awesome, thanks @RosarioPulella! Let's apply that to our app for now so we can move forward until there's a better solution long-term from the platform team.

[XAML-Knight]

Here are some more issues when testing WinUI 2.6:

• Horizontal focus/underline bar on top tab headers (Controls, Animations, Services, etc.) does not extend to full expected width:
  

• Unable to open ListViewExtensions (see similar Issue ListvewExtensionsPage Command prop not found #4039 )

• The following sample pages all have a similar issue to the Expander sample page, with a dark foreground color appearing, when a light foreground color is expected, mostly affecting toggle buttons in the right-hand Properties panel (but sometimes affecting the control itself):
  

• OrbitView

• TileControl

• IsEqualStateTrigger

• IsNotEqualStateTrigger

• PrintHelper

• BackdropGammaTransferBrush

• ClipToBounds

• ScrollViewExtensions

• GazeInteraction

[michael-hawker]

Thanks @XAML-Knight, are the list of pages underneath your initial issues ones with the similar problem or do they each have their own problem unique to that control?

If something is wonky on a system control (like ToggleButton) we should just double-check we're not using a custom resource for it, and if not we can file an issue on the WinUI repo to follow-up with after. For instance with AdaptiveGridView checkboxes that'd be this type of issue: microsoft/microsoft-ui-xaml#5392

Otherwise, I think the main things for us to focus on are things that were broken by the update like TileControl, or resources in our own controls that aren't aligned now to the new pattern (like Expander). Of course we need to determine if the new change is aligned to the new pattern or if it's a change we need to put back to how it used to be.

Can you work with @RosarioPulella to go through the things we've identified and break out the changes to address amongst the two of you? Then we can make sure we've filed any open issues against the platform team, and chipped at the initial work we have in the Toolkit. Thanks!

[XAML-Knight]

@michael-hawker

are the list of pages underneath your initial issues ones with the similar problem or do they each have their own problem unique to that control?

The controls in the bulleted list all had the similar problem.

I've reached out to @RosarioPulella to divide & conquer the changes to address.

[Rosuavio]

My findings so far are.
For the TileControl sample, for some reason the issue is the FlipView in the TileControl other wise the TileControl seems to work fine. Notably in WinUI 2.6 a some styles were added for the FlipView.

For the InfiniteCanvas the InkToolbarCustomToggleButton not updating it visual representation to who it has been clicked might be linked to the fact that in WinUI 2.6 a style was also added for InkToolbarCustomToggleButton. Other than that the InfiniteCanvas is fine.

I think an important issue to look into is this issue with buttons and icons being miss aligned/miss positioned/ sized improperly in a few controls ( BladeView, TabbedCommandBar and TokenizingTextBox) @XAML-Knight If you want to look into that I think it would help a lot.

On a lower priority some colors not looking quite right seems to be a bit of an issue too. The big one being the buttons on the Blades now blend into the Blade a little too much. And the Expander color issue is also an interesting one but it seems to depend a bit on the users system color theme.

[Rosuavio]

I think this improved the BaldeView well enough for now. It seems like perhaps this hints at a larger issue for rebasing all the controls to use as many WinUI styles of system styles as possible.

[Rosuavio]

It seems to look a lot better, on dark and light system themes.
Found it here
https://github.com/microsoft/microsoft-ui-xaml/blob/5e815a2c4bfe2bc019562b01fffbeeb25866acf6/dev/CommonStyles/Common_themeresources_any.xaml#L185

[XAML-Knight]

Looks good in Dark theme, Light theme ... a little less so. No telling if/when WinUI will move the goal posts on Light theme.

[Rosuavio]

This seemed to go well with it.

[XAML-Knight]

For BladeView, borrowing style components from the InfiniteCanvas can improve the visibility of the buttons:

<Style TargetType="ToggleButton">
	<Setter Property="Background" Value="{ThemeResource SystemControlBackgroundChromeMediumBrush}" />
	<Setter Property="Foreground" Value="{ThemeResource SystemControlForegroundBaseHighBrush}" />
</Style>
<Style TargetType="Button">
	<Setter Property="Background" Value="{ThemeResource SystemControlBackgroundChromeMediumBrush}" />
	<Setter Property="Foreground" Value="{ThemeResource SystemControlForegroundBaseHighBrush}" />
</Style>

[Rosuavio]

For BladeView, borrowing style components from the InfiniteCanvas can improve the visibility of the buttons:

What do you think about the changes I made though?

[Rosuavio]

For the Expander I can employ a similar technique as what I used for the BladeView, look at the WinUI lib and see what I can take from there. For Expander the obvious place to look is WinUI's own Expander. I am going to try to use there styles, but I would warn is it significantly different. A big think is that it dose not reflect the users system background color and it just keeps with the system theme (light or dark). @michael-hawker let me know if you think this is works for us.

The WinUI Expander for reference

[Rosuavio]

It seems fallowing some of the styles from WinUI fixed the issue and kept the expander reflecting off the user's system accent color.

[michael-hawker]

On me to review, but we also need to know status of microsoft/microsoft-ui-xaml#5468 for shipping 7.1

[michael-hawker]

@RosarioPulella I think for now we can leave our updates, and do another pass in a different PR to try and adjust/update styles more. At least we're functional. We can evaluate which controls make the most sense to focus on updating first and split those out individually among the team.

I'm going to merge this for now so we can move forward.