Creator of Rufus outlines the problems with Microsoft's UWP
github.com
github.com
He missed two important point that really puts me off.
The continuous reboots since Windows 8 was introduced.
The complete lack of respect for paying customers to deprecate C++/CX in name of ISO C++17 compatibility, with C++/WinRT, without any kind of Visual Studio tooling support, even after 4 years in development.
So now any .NET Native developer that would be dealing with C++/CX for those APIs that the WinDev refuses to create WinRT bindings, needs to write IDL files without any tooling, copy and merge generated files into their projects.
Wait for ISO C++ to get reflection and maybe we will do something about it they say.
Sometimes I get the feeling WinDev requires Notepad as their IDE.
Speaking of .NET Native, it is in maintenance, expect nothing beyond .NET Core 3.1 / C# 7.3.
When I was involved with Win32 Office, this (or the moral equivalent with VS Code) was often the case. Proper Visual Studio support was kludgy and difficult to maintain, and many (myself included) did without.
Most of the major desktop product groups have 30+ year old codebases and sure as hell aren't working off the latest C++, let alone C++/WinRT bindings. They've got other tools, or just put up with the drudgery because it's all they know.
How else can someone praise C++/WinRT versus the capabilities of C++/CX, which was finally something on the Microsoft side that could be compared with C++ Builder.
Sure it is an uplevel from WRL, however almost no one outside Redmod ever cared that WRL existed.
The only way to consider C++/WinRT on its present state as good is if the person in question never knew anything better, including MS own tooling.
Don't expect much adoption love.
This is disappointing to me, even though I'm no longer at Microsoft, because it means that Windows is now the only major platform where there isn't an official modern platform-native UI toolkit that people are likely to use. Win32 isn't really a good choice for new applications because it uses an antiquated graphics implementation (GDI). Win32 also doesn't make it easy to tweak or extend the accessibility implementation of a standard control. All of this means that for developers of native applications, Windows makes it harder to do the right thing with regard to accessibility than, say, Mac or iOS. If WinUI 3 actually took off, it might fix this.
The team still has a lot of work to do; unpackaged applications still aren’t supported, for one. And even once it’s production-ready (next year?), I’m not sure it will be good enough to use instead of web UI.
I do quite like how easy it is to build UIs that work for both keyboard+mouse and touchscreens. But overall it’s basically WPF with a few improvements, and the worst parts of WPF (styling, verbosity) are still there.
WPF is supported in Expression Blend, the tool helps with both styling and verbosity. For optimal UX it needs a bit of support from within the application, to provide design-time data. Ain’t terribly hard to do, and helps a lot when working on WPF GUI apps.
WinUI is not currently supported in Blend.
The XAML is incompatible as the rendering engine doesn't expose the same feature set.
Well, our use case is not to rewrite everything yet one more time, a use case that apparently is hard to understand.
Designers aren't supported, yet another please get in touch and explain your business case kind of answer.
I found WinForms quite usable.
This is kinda amusing because WinForms is very popular among game developers for making tools and 3D editors :-P.
For .NET developers, WinUI still represents rewriting the UI and for stuff like Viewport3D or HLSL support, the advice is to learn C++, make use of SurfaceImageSource and rewrite the stuff directly in DirectX.
Quite a change for LOB developers, then there are the missing components as well.
For C++ devs, the aging MFC is more productive than dealing with IDL files without any kind of VS tooling support, all components are based on COM (hello boilerplate) and requires manually merging generated files into the project.
They say they are listening to us, however they still fail to deliver what we complain about.
Meanwhile those that can afford it, will just adopt Qt, Delphi, C++ Builder instead.
So expect most people to still ignore these efforts.
Windows basically has lost a decade chasing a pointless unification of desktop and mobile platforms. UWP turned out a turd, no matter how you look at it.
Except they seemed not to have gotten the message and still are asking for rewrites, with less capable tooling.
EDIT: The only thing Reunion seems to be good for is as migration path into Win32 for UWP apps.
This also applies for any professional apps that do not require extensive access to the file system.
For the rest of the stuff like system tools, arbitrary file editors, user interface utilities you need to run in full trust UWP is currently not suitable.
Media players are already a somewhat iffy proposition because playlists, subtitles or multi-part (video) files for example are the kind of multi-file file formats that don't work well with heavily sandboxed file access because of the implicit relationships between separate files that the OS doesn't know anything about.
For C++, the path to avoid XAML is to stay with legacy MFC, adopt Qt or C++ Builder.
For .NET, there is really no way around XAML, other than keeping using Windows Forms, or doing everything by hand calling the .NET classes that map into XAML components, regardless of WPF, WinUI or MAUI.
Then there is Delphi as well.
They should allow developers to directly distribute the software from their own websites, and for 3rd-party stores to sell and distribute UWP apps.
Wouldn't that simply be a sales commission again, just billed yearly?
It is not like something like C++ Builder and Delphi don't exist for 25 years now.