Windows 11 Themes: Update the behaviours of various controls to be more modern/inline with WinUI

[aquinn39]

It's great that the WPF visual styles are finally being updated for Windows 11, however, looking at the sample app, it seems all these changes are purely visual - WPF still has many behaviours that reflect the behaviours of the GDI Common Controls from 2006 - 2012 era. Part of modernising the UI is not just giving it a fresh coat of paint to hide all the old things, but to update everything - both visuals and behaviour - to offer a better user experience. Specifically, these are the things I've noticed so far:

• Delta value is ignored when scrolling in ScrollViewers - resulting in a terrible scrolling experience when using a touchpad as it's far too sensitive and jumpy. Fixing this would also help give Windows touchpads a better reputation. In WinUI, scrolling is smooth and precise. More info plus suggested fix here: https://github.com/dotnet/wpf/issues/5936
• When clicking somewhere on a Slider, the circle slowly moves to where you clicked. In WinUI, it teleports straight to where you clicked and can be dragged with the same mouse click.
• Horizontal scrolling is not supported at all in WPF. In WinUI, horizontal scrolling is supported. https://github.com/dotnet/wpf/issues/3201
• ScrollViewers have their PanningMode set to None by default, meaning that by default, they can't by scrolled by swiping with touch. Not a huge deal since you can just change that property or even create a style for the whole application to set a different default for this property, but some devs don't realise this, resulting in a poor touch screen experience. In WinUI, ScrollViewers scroll with touch by default
• TextBoxes uses swipe-to-select to select text with touch. WinUI uses tap-to-select, which is better as it shows little circles which you can drag to move the selection and can swipe to scroll horizontally through the text.
• WPF still uses WISP instead of pointer events by default (Pointer events must be opted into). Pointer events are more performant and precise. Though, I'm not sure how easy this one is to solve as obviously compatibility with older applications needs to be considered. WinUI uses pointer events.
• WPF does not opt into visual styles by default. This means that certain system-provided controls such as message boxes, color pickers, font dialogs, etc. use Windows 95-era styles. Same with hosted controls in a WindowsFormsHost. The Application.EnableVisualStyles method from Windows Forms can be used to opt into visual styles in a WPF app - maybe this method could be copied over to WPF and called automatically on application startup?
• Swiping with a pen to scroll does not work in WPF - this feature was added in a Windows 10 update a while ago. This feature works in WinUI. https://github.com/dotnet/wpf/issues/5938
• The text selection visual is a faded colour on top of the text. Switch.System.Windows.Controls.Text.UseAdornerForTextboxSelectionRendering can be used to opt into a better looking selection visual where the colour is behind the text, but this is not the default. WinUI uses the better variant with the colour behind the text.
• WPF is system DPI aware by default. It supports per monitor DPI scaling so maybe it should be updated to be per monitor aware by default as many developers don't realise that they can opt into per monitor awareness. WinUI is per monitor aware by default.

I think updating many of these things is important, otherwise WPF looks nice on the outside, but when you go to use a WPF app, it still behaves as if it's running on Windows Vista or 7 in many ways.

[lindexi]

WPF still uses WISP instead of pointer events by default

Pointer still has a lot of problems, such as https://github.com/dotnet/wpf/issues/8517 and so on.

But the core problem is that WPF's touch and mouse are separate from multiple different events. And at the bottom of Windows 10 or Windows 11 WM_Pointer and WISP(RealTimeStylus) are the same set of things.

[aquinn39]

To add to my point about WISP, https://github.com/dotnet/wpf/issues/8435 would need to be fixed if pointer events were made the default, otherwise all WPF apps would crash on launch on Surface Pro 9s.

[lindexi]

@aquinn39 I do not know if it's Surface's problem or Wpf's problem. Do you think WPF should be compatible with Surface Pro behavior?

[aquinn39]

@lindexi Yeah I'm not sure, I'm just documenting it here. To me it seems like a Surface Pro 9 issue since I don't see why the minimum value should be greater than the maximum value. Still though, maybe WPF should resort to disabling its touch support or something instead of bringing down the whole application in this scenario?