Without more details, this is the way to get the most native Windows 11 look and feel:
https://learn.microsoft.com/en-us/windows/apps/winui/winui3/
Disclosure: I work at Microsoft on a team that works on visual look and feel for Windows.
https://learn.microsoft.com/en-us/windows/apps/winui/winui3/
Disclosure: I work at Microsoft on a team that works on visual look and feel for Windows.
https://microsoft.github.io/windows-docs-rs/doc/windows/UI/i...
WinForms is very old and doesn't do DPI, but one thing I like about it is that it always works.
By comparison when Windows 7 was released, enabling glass was documented and usable from any language or framework.
It's also not currently possible as far as I know to mix new controls and old controls in one window very easily - there are islands, but they seem on the macro scale (from when I last looked.) This makes updating apps difficult: changing a UI is an all or nothing upgrade per window. You can't just easily add WinUI to an existing WinAPI window in an app using a non-C#/Microsoft language. So people who have existing apps or use a non-MS dev environment are faced with enormous barriers.
The ties to Microsoft languages and IDEs are also troubling. It's not technically MS-only, but it is _effectively_ MS-only.
This is my personal account (I don't have a professional HN account) but I work at a company that produces a dev environment and IDE, and we run into these issues. I find that searching for my HN username and LinkedIn ("vintagedave LinkedIn") will likely let any reader (the OP, any reader, or u/ fassssst if you'd like to get in touch?) find me, and I'd be happy to speak on a personal or potentially professional level about issues with WinUI and what could be done to make it more accessible across dev environments and more easy to convert to or upgrade to.
This always infuriated me on Windows, and a big reason I moved to macOS.
This is a great read: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
> ...the biggest problem is that USER [API] is essentially inextensible. If a developer wants to create, say, a menu that acts exactly like the standard operating system menu but with some small extra feature (for example, he might want to support the drag and drop, similar to the Favorites menu in Internet Explorer) he generally has no option but to reinvent the entire menu system from scratch.
Seems like the failure of the Longhorn project really messed things up. It was suppose to replace the janky old win32 with .NET managed APIs.
I just remember XAML/WPF/.NET being incredibly slow. And choosing a managed language for OS stuff seemed bad. I can't believe no one was doing a quick POC and saying: this is too slow.
You have to give credit to Apple platform team. They have some real visionaries there. They had the guts to ignore garbage collection even when it was taking over the entire software industry. I guess MS just needed a competitor for Java.
I have never had so much confusion in my life. WinUI 2, WinUI 3, C++/WinRT, C#/WinRT, C++/CX, C++/CLI, WinRT (Windows Runtime - that's not a runtime), COM, C++ Win32, C# .NET, UWP, Fluent, Metro, .NET MAUI, PWA, React Native for Windows, WPF, Windows Forms, Windows API, Windows App SDK (which is WinUI 3), VSIX, XAML, .winmd, WebView2.
When I think about macOS: Swift + SwiftUI, Swift/ObjC + AppKit.
This article was a huge read but helped me get an idea of things: https://arstechnica.com/features/2012/10/windows-8-and-winrt...
I think the issue is that the writers are trying to be too delicate to not make people feel like their apps are using legacy technology that will be deprecated.
> Many apps for Windows are written using WPF or Windows Forms, and they remain viable tools today...looking to the future....
There should be one obvious recommended way to build new apps, and all the other docs should be moved to a separate section.
And when I install Visual Studio 2022, it has a "Workload" called "Universal Windows Platform"...but I just read this is deprecated!!
I honestly don't think Microsoft has the balls or ability to set a singular way forward at this point. WPF/UML have both been pieces of hot garbage. So one more framework to rule them all probably isn't something they're looking to explore at this point.
What should probably happen is that they make an announcement similar to that which they dis with printer drivers. "Beyond 2027, it must all look like this. Here is 4 years lead time. Get on the train."
ChatGPT gives a decent summary of the history of all that:
https://chat.openai.com/share/6478dcdd-98d3-449a-84be-be5666...
My own personal outsider take on this is that there are really only three eras that need to be considered:
- "HWND era": win16/win32 classic UI aka "WinForms". This extends all the way up to ActiveX. Microsoft get to dictate the platform without real competition.
- XAML era: the second system. Classic WinForms doesn't handle high-DPI displays or GPU rendering; it relies on pixel positioning and lets you draw directly on the framebuffer. WPF is the reaction to this.
- Phone era: suddenly there is real competition and users start using a lot of non-Microsoft platforms. Microsoft launch their own phone, complete with new sandboxed APIs that don't correspond to Win32 at all. This is ultimately a market failure. But Microsoft have invested too much in UWP.
At this point, the winning stacks globally are, in order: web (including Electron), iOS, Android. Nobody wants to do native Windows applications that aren't games if they can possibly help it. Even Microsoft start building web-on-desktop apps like Teams.
So the only thing Microsoft can do is salvage operations on UWP APIs and XAML-related techs to try to make it usable to desktop developers by getting out of the sandbox.
I had thought XAML was it and was ahead of the game, but it's kind of a different approach.
All the new ones define their declarative UI as inline source code.
I remember a while back there was contraversy that MS wanted people to write Windows apps for store in TypeScript. What happened to that?
https://learn.microsoft.com/en-us/power-apps/powerapps-overv...
Yeah. Unfortunately, Windows is not Python.
Even Python is not Python these days.
$ python
>import this
The look and feel is great though, Win11 is a nice step up from 8/10 in that department. So good to have depth, curves, transparency, etc back again.
The overhead of WinUI3 is pretty huge. The visual designer, a winning feature of Visual Studio for decades, is AWOL. Why? It's XAML, the same as the previous XAML designer! It's just .. broken?
The backward compatibility story is a disaster: you can get stuck in the UWP sandbox https://github.com/microsoft/WindowsAppSDK/issues/1780
What's the big Microsoft WinUI3 flagship app, then? Something people are actually using? Rather than just a few system dialogues. (How many Win11 settings pop up a Win32 dialogue box, still?)
WinUI 2 and WinUI 3 currently share the same look and feel but new apps should use WinUI 3.
Other than apps written by the Windows team and shipped with Windows, what's the flagship WinUI3 app?
How large is the actual WinUI team, approximately? We can make guesses from the number of committers on github, which appears to be about half a dozen people? It just doesn't feel like Microsoft themselves are really committed to making it work and then forcing it on Office or Teams.
At some point soon I'm going to have to do a native app to do driver control, and it seems the elegant simplicity of WinForms has been lost compared to how much "runtime" nonsense is hiding underneath the two different WinUI2/3 implementations. (You've done a Python 3 there!)
I'm sorry, but this is a massive step back in usability. I'm not moving from a system where I can drag/drop UI elements into place to one where I can't.