Question: Will Microsoft be updating the styles of wpf, winforms and win32 controls to be inline with the FDS and WinUI?

[Poopooracoocoo]

https://github.com/dotnet/wpf/issues/1485 and if there's a relevant winforms issue, add a link to it here.

[ianhan]

I can't see how updating default styles for legacy win32 or .net forms controls would break legacy apps being ported to .NET Core.

[Gavin-Williams]

It would break existing layouts if the update was anything but the most trivial change - a change that would most likely be already supported anyway under those frameworks. Think about it - any change you make will impact all those existing apps that use those frameworks and the UI dev's expect that the UI style is going to be the same next month as it is this month. Those old frameworks should be left alone to fade away with dignity.

If you want WinUI, use WinUI.

[ianhan]

Allow me to try and help you by explaining my point of view. I worked on Windows for 15 years, including in the Themes code, the common controls, and DWM. I don't think changing the look and feel of any of these controls will break existing layouts. It's simply a skin. Prior to joining Windows I spent 5 years changing the look and feel of everything from another company, Stardock. I think an effort could be made to try and come up with a unified look for the controls that doesn't break your layout. These frameworks have been updated over the years along with every new framework that Microsoft has come out with. I think if you're thinking they should fade away with dignity, you're missing a goal of project reunion.

If you want to be pro-WinUI, that's great. Go focus on WinUI.

[Poopooracoocoo]

The spacing/padding, sizing and layouts do not need to change but MS has already changed the size of the search and address bars in File Explorer and Control Panel so it proves that it's possible. And the colours and font sizes can easily be changed, provided that developers haven't hardcoded anything. If they haven't, then they're expecting their app to follow the system. Remember the msstyles api? And updating the icons in %SystemRoot%\System32\SHELL32.dll would be pretty trivial. Icons with higher resolutions are another story though of course.

I just want a little bit of consistency.

[Poopooracoocoo]

Yeah, it's not real FDS (which is a rather abstract "system"), I agree.

I'm not against change, I'm just saying that is not necessary

but what about the visual style of the controls themselves as I mentioned above and in that other issue?

[Felix-Dev]

One important aspect for me is how many resources this will require from MS to modernize existing controls like WPF controls or the wrapped WinForms controls and where these resources could be put to good use elsewhere otherwise. At the end of the day, MS only has so many resources and I personally would like them to focus on WinUI and non-UI API surfaces to bring UWP and Win32 closer together (just take a look at the many sophisticated requests open in the WinUI repo the developer community is very vocal about).

Now, I get the appeal though. If you have a huge WPF/WinForms app, getting the new Windows 10 Design look for it without having to do much at all - that will certainly sound great to developers of such apps.

Even if MS will not invest into the WPF, WinForms, etc... UI controls to match the Windows 10 Design language, it's not like the community won't have any options here. WPF, for example, has the Modern WPF community project - bringing Fluent Design to WPF. The existence of such community pojects should factor into the decision whether MS will have to - presumably - invest considerable resources here which could also be put to great use elsewhere for the developer community.

[ShankarBUS]

Hey @Felix-Dev, this is what I was trying to say. I had to delete my comments. I said the exact same things but @Poopooracoocoo didn't seem to understand my point.

[mdtauk]

It could be implemented as an opt in. New app templates can use it by default, and other existing apps could include a line of code or Xaml in App.xaml.cs that requests the updated Theme/VisualStyle/ResourceDictionary

[Poopooracoocoo]

@ShankarBUS didn't have to delete your comments :(

At the end of the day, MS only has so many resources

I'm only thinking about the appearance of controls like buttons and checkboxes. I don't think updating the radio button would be too complicated. And while I want WinUI to improve, I know some apps will never adopt it. Not even Microsoft has adopted it fully. And I assume that there are different people working on different things. And I've opened quite a few issues on the WinUI repo myself :p

[ShankarBUS]

@Poopooracoocoo,

I know some apps will never adopt it

Yes it is true 😅.

What my suggestion was there are 3rd party libs for this specific request.

You can always make a PR for the new FDS styles. We can't expect MS to do everything.

If done like @mdtauk's suggestion, no breaking will happen but someone has to redo the styles (which is already done in a 3rd party lib) and add it to WPF's repo.

There is already a lib for FDS in WPF, which will exactly look like WinUI styles.

Your request is about updating just the visual appearance and not layouts. Which will be incomplete and disconnected from FDS guidelines and will result in yet another iNcOnsIsTeNcY in Windows.

didn't have to delete your comments :(

Sorry I felt my comments were a bit stupid 😂😅 and tangent to this issue's context. I'm not against updating the styles, I felt it will be incomplete when compared to WinUI

[Poopooracoocoo]

Your request is about updating just the visual appearance and not layouts. Which will be incomplete and disconnected from FDS guidelines and will result in yet another iNcOnsIsTeNcY in Windows.

Of course it's incomplete but it's a step towards consistency. Inconsistencies aren't being created as you implied.

What my suggestion was there are 3rd party libs for this specific request.

Devs shouldn't have to use them. I also don't think it should be opt in. Consistency should be the default. ModernWPF's styled controls could be really useful.

We can't expect MS to do everything.

Microsoft still uses non-WinUI frameworks in various places. Including Office. They advertise Office 365 heavily and so I expect them to care about their own product/service.

If anyone from Microsoft does read this, here's a nice read: https://docs.microsoft.com/en-us/windows/win32/controls/visual-styles-overview It's sad that the article hasn't been updated since 2018 or for Windows 10. Some controls were updated for W10 but haven't been updated recently to be inline with WinUI's more recent changes to the checkboxes, radio buttons and corner radii.

[jonwis]

Project Reunion will not alter the core Win32 controls in comctl32.dll that are part of Windows and used by existing applications. As others have noted, such a change would be challenging to pull off across the breadth of the Windows app ecosystem.

If you’d like to use modern style XAML-based controls in your Win32 app please keep an eye on WinUI 3. You’ll be able to drop a WinUI 3 control into your existing applications to start applying your own theming and branding to them.

[Poopooracoocoo]

@jonwis Microsoft probably won't be using WinUI 3 in Office or in Windows. I doubt that all of the settings in Control Panel will ever go to Settings. And look at File Explorer. Even if it and the other system icons aren't getting Office-like icons, it'd be nice if it looked a bit better. The whole point of updating the styles is so that existing applications get the new styles.

As others have noted, such a change would be challenging to pull off across the breadth of the Windows app ecosystem.

That's only challenging if you change any sizing, layouts or padding. This question/request was only about the styles. The main things I had in mind are chevrons and arrows, radio buttons, and checkboxes. WinUI changed the style of radio buttons. WinUI is the only native UI framework that has that style right now.

Super disappointed but not particularly surprised. I'm disappointed in myself for thinking Microsoft could ever change or was ever different.

[Poopooracoocoo]

@jonwis here's some proof of old UI in Office 365:

[DragoCubed]

Here's a relevant issue: https://github.com/microsoft/microsoft-ui-xaml/issues/1258 Microsoft needs to commit to a style. Don't pretend that Microsoft doesn't own Windows. Not even Edge uses the new style in its React pages or for HTML forms. And then there's rounded corners. It's very difficult to go back when tiles are so infused in Microsoft's design language. The Office and VS icons still use that design language and so do the Windows and Microsoft logos. commitment issues much

[lorisobi]

I do not really understand this. Microsoft updated the Win32, WPF and WinForms Controls with every major Windows Version before Win 10, to fit a modern style. Why should this now be such a big problem?

[JaiganeshKumaran]

Instead of updating the styles to make it look like WinUI, why not modify the Common Control APIs to internally render WinUI controls. This way all Windows apps will get modern look without recompilation or anything. Simply an OS level change. This will not have any compatibility issue. The only issue is with Windows PE which doesn't have XAML but they can keep the old implementation or implement WinUI there.

[Poopooracoocoo]

@Jaiganeshkumaran or just update the styles like they did with Windows 8 and the first release of Windows 10?? It'd be heaps easier and they've done it before. The Windows shell isn't using WinUI yet anyway

martin anderson made this awesome timeline:

[JaiganeshKumaran]

@Poopooracoocoo It wasn't really consistent. Instead Microsoft should reimplement them and make them call WinUI APIs internally. Windows shell already uses UWP XAML so it can be easily moved to WinUI.

[prayaas-a]

@Jaiganeshkumaran or just update the styles like they did with Windows 8 and the first release of Windows 10?? It'd be heaps easier and they've done it before. The Windows shell isn't using WinUI yet anyway

In the latest Windows Insider Dev builds, there are apparently some pdb symbols that refer to WinUIStartMenu and WinUIDesktop - apparently Microsoft will be using WinUI to bring the new design changes they teased. Now hopefully it'll make it to more than just the taskbar and Start Menu (which already use a version of XAML). But yeah, skinning really shouldn't be that hard - maybe Reunion team can forward these requests to the Windows dev team if they're not already working on such a thing.

[Poopooracoocoo]

I've heard about that too. It's taken them way too long! There's stuff like the accessibility controls on the sign-in screen and the volume controls that are stuck in the Windows 8 era but they've probably forgotten about them

Reunion team can forward these requests to the Windows dev team if they're not already working on such a thing.

lol. it's microsoft.

[Felix-Dev]

@Poopooracoocoo The WinUI team, which now owns WPF, said in the July Community Call that they plan to update the WPF styles for Fluent Design. They also said they would like to see the community helping them out with this so if this is a major concern for you, you might wanna help out here if possible.

[sylveon]

@Jaiganeshkumaran Apps which mix custom rendering (performed with GDI in Win32 or WinForms, DX9 in WPF) with normal rendering will suddenly present significant airgap issues if this where to be done. Even more so when you can, in Win32 and WinForms, override rendering per control, meaning that everything essentially has to be rendered in GDI forever for backwards compat. It's too deeply engrained: messages like WM_PAINT, WM_DRAWITEM and WM_ERASEBKGND directly pass a GDI handle to the window procedure.

This rules out swapping the implementation for WinUI, which uses DX11. A lot of work would need to be done to make such a move work in all scenarios while also keeping existing apps working. Don't fix what isn't broken.

WinUI-like controls could be made, with enough efforts, but it would present a significant CPU performance impact, because GDI is not hardware accelerated. The most realistically doable options is color palette swaps, new assets for checkmarks/radio buttons, and some rounded corners. And that's effectively what most of the things in @Poopooracoocoo's image are.

[JaiganeshKumaran]

@sylveon Microsoft can have a option to use old GDI or WinUI for GDI APIs. By default this should be WinUI for all apps but apps can opt-out by just adding a few lines in app.manifest. This will make the experience more consistent at day one.

[sylveon]

Apps should not have to opt-out of radically breaking changes.

[JaiganeshKumaran]

@sylveon Or make a option for WinUI in the manifest and keep GDI as it is and keep the default. Rewriting existing UIs is hard so just changing the API means everything will get modernized. That's what Apple does

[Poopooracoocoo]

and look at issues like this: https://bugreports.qt.io/browse/QTBUG-67630

Qt isn't doing anything special. It's Windows 10 that has Windows 7 era elements. Even the Windows 10 (aka PE) installer has a Windows 7 window frame. I see it every time I install Windows 10 in Virtualbox.

[lorisobi]

It's a shame that this issue is closed - how do they want to achieve consistency?

[prayaas-a]

It's a shame that this issue is closed - how do they want to achieve consistency?

I see that we're trying to get someone at MS to spill the beans on Sun Valley ahead of that event 😜

[Poopooracoocoo]

Microsoft did it