Currently 2307 issues open, https://github.com/microsoft/microsoft-ui-xaml/issues
And this is just one repo, then you can hop into C#/WinRT, AppSDK, C++/WinRT ones as well.
Hence why they keep releasing WinUI 2.x series, although 2.6 was supposed to be the very last one before WinUI 3.0 goes stable.
However if you go to the community meetings everything is rosy and we should all be jumping into WinUI 3.0.
I just got an internal email saying "MS has a very convoluted process for getting a developer account just to publish apps to the Microsoft store and not even our MS rep knows the correct answer" from the person trying to set that up, so that's going well too.
On the outside it looks they have made a mess across teams, and now everyone is competing for our attention regarding Forms, WPF, WinUI 2.x on UWP (XBox, HoloLens, Windows until WinUI 3.0 catches up), WinUI 3.0 (some day), MFC (WinUI with C++/WinRT is a mess except for ATL/WRL fans with their deep IDL/COM love), MAUI, PWAs, or better yet, just wrap Blazor everywhere.
So I can't belive they are like the dog on a burning house, rather not allowed to fix the mess that Windows 8 brought into Windows development, and talk publicly how they actually think about all of this.
And they've never quite dealt with having their platform be eaten by the web and the Apple Store / Google Play Store. See https://blogs.windows.com/windows-insider/2021/10/20/introdu...
There's also the tension between dotnet core trying to be properly cross-platform vs having it actually support the various Windows toolkits. They've historically been welded into the build system as first-class citizens, rather than optional packages, which causes trouble as soon as you do a cross-platform build. WinUI3 goes halfway to fixing that by being installable as a package, but still relies on "<UseWinUI>true".
As pjlmp says, that would be an admission of failure.
I lost count of how many PMs I got to see on comunity meetings since the Windows 8 days.
They also pretend that all the rewrites that keep being requested since WinRT was introduced, and rebooted on the process, aren't a big deal.
When faced with these questions they always ask for us to explain our viewpoint, as if it wasn't clear for them to start with, of course it is clear, but they cannot say it live.
The "Disable hardware acceleration" setting, when present, still frequently makes all sorts of desktop software run faster and less buggy.
>I believe what you’re doing is describing something that might be considered an entire doctoral research project in performant terminal emulation as “extremely simple” somewhat combatively.
And I guess DirectDraw lacks a fast API to do colored text?
In all that time, as computers have got blindingly fast, the one and only constant is the guarantee GUIs continue to get get slower.