Replies: 70 comments 548 replies
-
|
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you! Closed similar issues:
|
Beta Was this translation helpful? Give feedback.
-
Component Vendor Support for WinUI3All the component vendors already know it. Telerik
The two "under review" haven't been updated since about a year. Ref: https://feedback.telerik.com/winui SyncfusionThe WinUI roadmap for 2024 includes only improvements to shared components (i.e. improvements are made for multiple platforms) but nothing specific to WinUI3 controls. Ref: https://www.syncfusion.com/products/roadmap/winui-controls DevExpressThey are explicitly stating that their WinUI3 components are dead:
Ref: https://supportcenter.devexpress.com/ticket/details/t1206625/winui-3-the-roadmap-in-2024 |
Beta Was this translation helpful? Give feedback.
-
|
@NicholasChrzan Wow... |
Beta Was this translation helpful? Give feedback.
-
|
Honestly their a lot of reasons, maybe the client do not want anymore a GUI who look like Windows XP ? And DevExpress WinUI component is free while WinForm cost 999$/year, so Devexpress will not push clients to use a free component |
Beta Was this translation helpful? Give feedback.
-
Hardly anybody uses the built-in WinForms controls for professional applications these days.
Probably you haven't read everything: They stopped development. And they always do like this when they are starting to target a new platform: The initial versions are free for a while until it's mature enough to charge for future versions. MAUI controls are free as well, for example, as it's still in development. |
Beta Was this translation helpful? Give feedback.
-
Ho, was not aware about this. My bad. |
Beta Was this translation helpful? Give feedback.
-
Cannot clients just install another theme if they don't like a XP-like theme? When finally all apps stop having hardcoded themes in them? |
Beta Was this translation helpful? Give feedback.
-
ConsequencesIf this turns out to be true, this would be a severe incident: 1. You owe me two days of workFor creating the Pull Requests, since I didn't know that they'll be never even looked at due the product being abandonded. Same goes for the effort that so many people have taken in order to submit bug reports or create design proposals. 2. Have Microsoft Representatives been Lying to the Developer Community?This needs to be evaluated. Behaving as if all would be fine and the product would be continued is quite close already. And I recall statements like "all developers are working on WinUI3 now" which I think were made after 2022 and after stopping development (largely), When the UWP bugs were all closed, it was promised that issues will be better handled in the future and it won't happen again. |
Beta Was this translation helpful? Give feedback.
-
|
WYSIWYG for WinUI3 says looking into it... but the only "official" microsoft feedback is the automated message when creating a topic, and a bot message for a deleted message. MS fixed a Co-Pilot bug that was reported witin ~a week, can't we be notifed that at least they are doing something? |
Beta Was this translation helpful? Give feedback.
-
|
Let's think about the crazy future where blazor rules next. There's also a possibility that they really have very few resources, and it's hard to be convinced that it's really production usable until ms actively migrates the existing own app. I'll wait until it supports NativeAOT before I try it. |
Beta Was this translation helpful? Give feedback.
-
If WinUI3 would be the future #1 desktop UI framework, then they wouldn't be assigning 20 times more dev resources on MAUI. The required qualification is not that different and MAUI cannot be a higher priority project than a native Windows UI framework which neither MAUI nor Blazor is. |
Beta Was this translation helpful? Give feedback.
-
They also once said that Win10 is the last desktop version, but the person who said this has been fired. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think so, it looks like a technical reorganization, nothing is brand new (uwp equivalent). Apart from the fact that I can't figure out why the designer isn't being offered, but it's very much trending the blazor of the dotnet community looks like it's going to win this one. |
Beta Was this translation helpful? Give feedback.
-
|
If you read through the issues here about it, you'll find some comments from a (now Ex-)MS developer exlaining why it's a huge task and why the UWP designer cannot be built upon. |
Beta Was this translation helpful? Give feedback.
-
|
Anyone who's been using XAML knows that any HTML/CSS equivalent is 🤮🤢 It's very unfortunate and painful but @softworkz you are so right. The most frustrating bit is the lack of an offical response to either validate or disproove it. All these posts here in an official repo, and not a single response from any official maintainer. |
Beta Was this translation helpful? Give feedback.
-
|
You need to read further down. There has been some movement. After my post Prediction: A WinUI3 Visual Designer is Coming they had responded by confirming it shortly after that post. Even though this discussion has gotten trolled away from the topic recently, I'm sure they do read this. Quite recently, the status was changed to "On the Roadmap" but 10 minutes later set back:
My interpretation is that it's still not to be expected very soon... |
Beta Was this translation helpful? Give feedback.
-
|
The irony of calling it 'some movement' lol |
Beta Was this translation helpful? Give feedback.
-
|
WinUI is mismanaged and woefully understaffed. I wrote a post up a while ago which got a lot of traction. Either close this repo and make it internal only and pretend that it's under active development or put it out of its misery. I love WinUI and it had great potential and traction but all good will has been lost by the lack of comms out of Redmond. Remember as well this whole UI framework and stack (WinRT) is as old as Windows 8. DPs of Win8 were available in 2010 or 2011. That makes the tech at least 13 years old. Appalling when you consider how much Android and iOS have iterated over that time. |
Beta Was this translation helpful? Give feedback.
-
I know it very well. ❤️ Your post had "inspired" me actually. After I had read it a few days ago, I had started investigating the actual dev activity which ended up in this: Great News: All Bugs Will be Fixed In the Year 2041, after which I dug deeper as it all didn't make sense to me.
Maybe that's one of the reasons for the decision to create something new (which I'm inclined to believe). |
Beta Was this translation helpful? Give feedback.
-
|
My suspicion is that they have pulled off the majority of developers to work on something new. Maybe they'll call it WinUI4 to make the whole story not appear even worse than it does already, but it must be on a very different technical basis. If it was a continuation only, they could have backported fixes and wouldn't have to invest into Xaml Islands. Also the component vendors wouldn't have had to pull their efforts if it wasn't something technically different that is coming. And it's clear that something must be coming: the framework gap on Xbox needs to be filled. App development for xbox is not abandoned, WebView2 for Xbox has just been released in November and UWP is been given up, so there's an obvious gap as Xbox is meant to stay. |
Beta Was this translation helpful? Give feedback.
-
|
The strongest evidence of all is the component vendors' behavior. I mean, MS doesn't make a call to DevExpress like "Oh, we just wanted t let you know that WinUI3 is dead. Sorry for your wasted effort. Goodbye". It would rather be something like "We want to have you on board from the early stages on while we are developing a successor technology to WinUI," Another reason from which I find it very plausible that they switch onto something new is the WinUI3 source code and build system; When you see that and move a little bit around everywhere, then - at least in my case - you'll just want to run away and do something else... ;-) |
Beta Was this translation helpful? Give feedback.
-
This could be a good thing, the future could be the realm of declarative UI frameworks and blazor, which could be echoes of Longhorn from twenty years of unfinished visions (everything is dotnet). I have no doubt about that with their now frantic embrace of web technologies. |
Beta Was this translation helpful? Give feedback.
-
|
Now and in the future, there are and will be many UI frameworks. But this is about the operating system's native UI framework, i.e. by which the OS components themselves are developed, so I doubt that it will go in any such direction like web. But a .net-based rewrite of WinUI3 is something I could well imagine. It's actually my nr 1 theory. |
Beta Was this translation helpful? Give feedback.
-
Correct me if I am wrong but isn't half of the Windows 11 OOBE just a WebView2 already? Like some pages in the Windows settings app and the recommendation/ads part of the start menu. The newly revealed Windows 365 Link is just a login screen and it is entirely web based as well. Looks like Microsoft will turn every UI |
Beta Was this translation helpful? Give feedback.
-
there is nothing wrong with HTML compared to trash microsoft made like xaml before |
Beta Was this translation helpful? Give feedback.
-
|
Also the fact that they even converted this serious issue to a discussion to show us how much they don't care: #9154 ...Or at least they don't care that this UI framework is only usable for simple mobile-like apps and don't care that it's unusable for any complex business application. I seriously doubt that something like Visual Studio could be made with WinUI 3, so it's not a replacement for WPF. |
Beta Was this translation helpful? Give feedback.
-
|
I interpret it as - they don't care about this discussion as an issue. |
Beta Was this translation helpful? Give feedback.
-
PredictionWhenever they will respond to this, directly or indirectly, one of the first statements will of course be saying that WinUI3 is not dead and will continue to be supported till the end of days (or at least according to the OS support periods). (Yet, that's what I mean by saying that it's dead) NoteI have no insider information on this subject. If I had (like at some occasions in the past), I wouldn't post about it. It's solely based on observation, inference and deduction (and experience from similar cases). There's a chance that I could be wrong, but I don't think so. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately I think you're right. I just really hope they don't go the web route, even for native apps. But even if they don't, the fact that they're creating yet another UI framework/application model is just... They keep making new and new ones and then replacing them with new ones just 3 years later, and those who invested in the previous technology are s*** out of luck. First (that I remember) Windows Forms, then WPF, then Silverlight, then Windows Phone + Windows 8, then UWP, then WinUI 3… all incompatible with the previous ones. Oh and in parallel, Xamarin and then MAUI. I’m afraid it’s going to happen again to WinUI 3… And then Microsoft says that they "care about compatibility".... while leaving developers who are stuck on the previous thing behind. This isn’t how to treat your developers well, Microsoft… Can’t they for once stick to a single framework and work on making it the best it can be, and making the developer experience the best it can be? |
Beta Was this translation helpful? Give feedback.
-
|
It would also fit into the timeline. I dug out whe roadmap document from the history where it was said that there's a new team: https://github.com/dotnet/wpf/blob/be08c08b0cddfe075b8535ab7b3b591113d2f3c2/roadmap.md |
Beta Was this translation helpful? Give feedback.
-
I really don't think so. And even if they did, they probably wouldn't abandon their flagship native UI framework. Lots of people write native apps. There isn't just .NET out there. And Windows apps themselves need to use something and most of them are not C# (although I know Microsoft Store is (was? not sure if it still is)) |
Beta Was this translation helpful? Give feedback.
-
|
Agreed that it cannot be a replacement. It's merely a question of focus. |
Beta Was this translation helpful? Give feedback.
-
Walled Gardens on Android and IOS literally killed C# and Java. There is no reason to use virtual machine languages when Android and IOS and Windows walled each other. |
Beta Was this translation helpful? Give feedback.
-
|
But why one cannot just stick to Windows Forms? That's the most capable framework, and hardly will be dropped any time in foreseeable future. |
Beta Was this translation helpful? Give feedback.
-
|
I should mention that the WPF team has recently been activated and is providing WinUI 3 styles and controls.
Also, I must mention that there have been good changes since wasdk v1.5 and we will have good changes in 1.6. |
Beta Was this translation helpful? Give feedback.
-
Yea, in no other Windows UI framework I had to send WM_CLOSE to my own window to close it |
Beta Was this translation helpful? Give feedback.
-
And more importantly, it can be run cross platform, even on Linux, thanks to Avalonia XPF, like I said in #9417 (reply in thread) |
Beta Was this translation helpful? Give feedback.
-
|
It's a civil war at Microsoft, and the winner is the WPF |
Beta Was this translation helpful? Give feedback.
-
This is false. At least for C++ :p |
Beta Was this translation helpful? Give feedback.
-
|
WPF is aging, and unless they rewrite the backend to directx 11/12 and fix the performance issues, it is unlikely to be the framework of the future, as much as I would like that. Supporting the styling of winui is just a solution to make legacy Microsoft WPF apps blend in with the new stuff. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Yes, it is sadly, but kind of my fault, wanting to use the latest technology for some UI improvement and specially trusting MS on new tech perennity. |
Beta Was this translation helpful? Give feedback.
-
Despite of all ranting about WinUI3, I need to say that 99% of such "crashes" are due to the way you are coding. In most cases, these are caused by threading and the way you handle events. private void UISettings_ColorValuesChanged(UISettings sender, object args)
{
this.DispatcherQueue.TryEnqueue(this.UpdateTitleBarColors);
}The DispatcherQueue is often presented as a measure to perform tasks on the UI thread. But another important use case is decoupling of event callbacks, which means that you should even use it in cases when the callback is on the UI thread already. It's not always needed, but unless you have gained some experience in which cases it may be needed and in which it's not, your best bet is to follow this rule unconditionally. When you are interacting with hardware and there's COM somewhere in-between your application code and the hardware, and you are receiving events from the hardware, keep this in mind as a general measure. A while ago, I've been working for a company who have a WPF application that is inferfacing with a range or hardware through different interfaces and in one case, they've been struggling for years with instabilities in hardware interaction. When I told them how it can be fixed, no one believed me, saying they had tried everything already and it would be MS' fault (and between the lines kind of "none of your business anyway"). |
Beta Was this translation helpful? Give feedback.
-
|
@softworkz unfortunately, the |
Beta Was this translation helpful? Give feedback.
-
@matthewacme - I think you are a bit confused. UWPIn UWP, there was no DispatcherQueue originally, just the Dispatcher property on the CoreWindow which gave you a CoreDispatcher. Same properties available on any DependencyObjkect. WinAppSDKIn WinAppSDK, both properties are available on the Window, but the Dispatcher property is always empty. Same availability with the WinAppSDK version of DependencyObject. So it's the same situation as with UWP. Framework-Agnostic WayInstead of passing around the queue, there's another way which works universally (UWP, WinUI, WPF..). All that it takes is that you need to set this up at a moment where you are sure that you're on the target thread ("UI thread"). For example, when you know that a class is instantiated from the UI thread, you can grab the System.Threading.SynchronizationContext: class MyClass
{
private readonly SynchronizationContext synchronizationContext;
public MyClass()
{
Debug.Assert(SynchronizationContext.Current != null, "SynchronizationContext.Current is null => not on UI thread");
this.synchronizationContext = SynchronizationContext.Current;
}
public void ExecInUiThread(string cmd)
{
this.synchronizationContext.Post(
_ =>
{
this.DoCmd(cmd);
},
null);
} |
Beta Was this translation helpful? Give feedback.
-
|
You should be cautious of the SynchronizationContext. Error handling is harder to do properly, especially if you also have async calls in there, since it doesn't natively support async/await. It would be cool if it did support though. |
Beta Was this translation helpful? Give feedback.
-
|
What's the point of this post? Don't think anything meaningful would come out of this. WASDK 1.5 and 1.5.1 was just out. Community call on 1.6 roadmap is posted. Are you some kind of PR guy to sabotage WinUI just to advertise WPF? |
Beta Was this translation helpful? Give feedback.
-
|
Not at all. I've been frustrated that my PRs are ignored and no action is taken on my and others' bug reports. And what I want is to be informed earlier in order to avoid investing into a technology with a limited future. |
Beta Was this translation helpful? Give feedback.
-
|
Also consider the following: Until 2022 they've been pretty responsive here to all kinds of posts, which has ceased almost completely. Lastly: I have no intentions to paint a false picture and just talk things down. You have my word that I will deeply and sincerely apologize to the whole team and fellow developers in case when it would turn out that I've been largely wrong. |
Beta Was this translation helpful? Give feedback.
-
|
I'm with @softworkz. We're not here nit-picking about issues in obscure features that few devs would notice. The fact is that basic functionality in WinUI is broken (e.g. this one) and nobody seems to be working on it. |
Beta Was this translation helpful? Give feedback.
-
|
I feel the slowdown in WinUI 3 fixes and new features is because WinUI 3 is also the Windows component of MAUI. So in this process many bug fixes get postponed and new features/fixes are delayed due to the testing cycle on all platforms. Plus of course the most important is the compatibility between the management of these teams. |
Beta Was this translation helpful? Give feedback.
-
|
Why would that delay fixes and features? If anything, it should accelerate them because they're needed for MAUI. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with Neme12. If anything, Maui's use of WinUI 3 should increase pressure to fix bugs. But then there is For the obvious reason that Blazor runs on the web also. "Web technologies everywhere" wins the UI future. Ah well, at least we get to use c# and .Net libraries. That's worth a lot. Microsoft might also have concluded that the future of "UI" is offerings from multiple vendors. I don't know what that means for Windows OS. But I see a common industry-wide theme in app development: "cross-platform, please". Consider |
Beta Was this translation helpful? Give feedback.
-
|
Also, based on the ignite session of integrating the Win App SDK with MS Office there was a large focus on React Native. |
Beta Was this translation helpful? Give feedback.
-
|
Do you guys realize how we're all talking to ourselves? Not even a single official comment or response on this whole thread. |
Beta Was this translation helpful? Give feedback.
-
Sad but true 😅 Idk why I'm holding out hope but I really am. I think it's because refocusing efforts on fixing all the papercuts would be so easy...we just need one person to understand and do it. Once you have a handle on all the papercuts present and how to avoid them in WinUI it's not the worst thing in the world, but yeah it's still bad. Why MS, WHY? COMMON GUYS, SERIOUSLY. WinUI3 is literally the epitome of death by 1000 papercuts, and all it would take is one MS dev to focus on and tackle all the low hanging fruit papercut issues for like...2 weeks? Maybe 4 weeks max....and we'd be in SUCH a better place. Stop piling features on top of a broken foundation. A designer would be great, but what good is a designer on top of a broken framework? Just stop. Do a papercut issue PR sprint with the whole team where everyone tries to close the max number of issues they can in 2 weeks and the winner gets a $500 gift card to Walmart or Amazon or whatever. Almost all our complaints would be solved in a couple weeks. But alas....as you said...I'm talking to myself... |
Beta Was this translation helpful? Give feedback.
-
|
Hello everyone, Mik from Windows team is here, thanks for starting the conversation. Now, it's obviously our platform is not in the place we want to be in the future - there is a big backlog of items that we need to triage and prioritize among different internal and external customers. One of the strongest feedback items we've heard consistently that Microsoft is not using the same technologies we are recommending to developers, and we are working on that too. I think one other area your feedback attributes directly is that our platform is not fully open sourced, we make source code available, but there is not currently a way for community to directly contribute to the release. You can watch the discussion about this topic during our latest WinUI Community Call with specific details. We continue to invest in frameworks Windows developers use. For example, we've recently shared our refreshed roadmap for WPF on GitHub - https://github.com/dotnet/wpf/blob/main/roadmap.md Windows will continue to be an open platform for developers. |
Beta Was this translation helpful? Give feedback.
-
This is the worst part, not using your own native framework for your own first party apps, that should be a showcase of your own technology, it's a really bad that leads devs asking their selves: "why should I use this if not even Microsoft does?" ... especially considering that most of them moved to inferior, slow, heavy, pen&touch unfriendly web tech (including some OS controls). |
Beta Was this translation helpful? Give feedback.
-
This is absolutely my No. 1 criteria and a potential dealbreaker. In the old days (MFC, etc. - yes I was there) - we knew your developer tools were golden because you were using them. The primary reason I started getting interested in WinUI again is because MS is starting to actually use it more, including in the Windows shell. That plus 1.5 being a huge improvement I feel like things are starting to finally get on track and you have a viable contender for a WPF successor finally. But here's my feedback for y'all - you NEED TO FOCUS. I feel like I'm looking at a menu at the Cheesecake Factory here. There are too many damn options and none of them has everything I need. I love WPF, and if you're gonna go with that one as the winner then go with it and kill RT once and for all. If not, let WPF die and beef up WinUI so it's at par. Or if you think cross-platform incl. web is the ultimate future then go all in on MAUI and for Windows put it on top a Skia or D2D renderer and kill everything else. Regardless, please, enough with having 15 different flavors of frontend frameworks where none of them is rock solid. Even the most valuable company in the world can stretch itself too thin. You're like the Roman Empire, too big to govern itself. You need a single "Frontend Development" czar who can make sense of all this and unify it and assign the resources more sensibly. Instead you have a bunch of independent little kingdoms between Blazor and MAUI and WinUI and WPF and React Native and whatever the heck you guys use internally 10+ years after Windows 8/Metro disappointingly little progress has been made. All there are are more options, layers built upon layers, and none of which is the whole package. |
Beta Was this translation helpful? Give feedback.
-
Funny you claim web is slow while C# is even slower. What a joke |
Beta Was this translation helpful? Give feedback.
-
What a troll! |
Beta Was this translation helpful? Give feedback.
-
|
Another name I've never seen before. What's with the high employee turnover rate? Are people who don't care for the product being hired? Is it terribly mismanaged? Is it just impossible to fix that you're all getting burned out? Dare I say something about gen z? I should add that I don't deal with Windows development anymore. Here purely out of curiosity as I, like many other developers here, invested many years of my life into these things. Microsoft couldn't get things together so many B2B apps have gone web for desktop and native on mobile. Does have its downsides of course, but what doesn't? |
Beta Was this translation helpful? Give feedback.
-
|
I'm interest in WinUI for about 3 years. But I don't see any advantage compare to WPF yet. |
Beta Was this translation helpful? Give feedback.
-
|
apparently it is being tracked here #6527. but to be honest this does not really affect my case since what i want is to overlay winui controls over the webview which other alternatives cant provide. |
Beta Was this translation helpful? Give feedback.
-
Do you know if this applies only to the WebView2 in WinUI or to WebView2 generally? The IE ActiceX WebBrowser control not only allows transparency (by keying out a color) but allows mouse events (click & hover) to selectively fall through to the window below. I was able to get transparency working in WebView2 (outside of WinUI context) but never the desired mouse behavior available in the old WebBrowser controls. |
Beta Was this translation helpful? Give feedback.
-
|
It's not a limitation of the WebView2, but of WinUI3 composition. The WebView2 sends its content with transparency, but on the WinUI3 side, transparent areas will be painted on top of the window background color. Due to the same limitation it's also not possible to have transparent content in a swapchain panel. Transparency works in all cases where the WebView2 is rendered to a Win32 window (with hWnd) and also in case of UWP (DirectComposition). For input event forwarding, there's no built-in way. Since no simple color keying is used, there's also no yes/no regarding whether an input even should be handled inside or outside. I see three ways to do that, though:
|
Beta Was this translation helpful? Give feedback.
-
|
Wow, thank you for this very knowledgeable and helpful reply! I appreciate you pointing this out:
It had not occurred to me that transparency via color keying (which is visually inferior, as you pointed out) was the very reason why the natural selective mouse fallthrough behavior I observed was so easily achieved in IE WebBrowser, and so there's a genuine tradeoff here, not just a bug waiting to be fixed by the WebView2 team. I recently saw this Electron demo (must wait for gif to load, then click play) of exactly the mouse behavior I wanted (note how the mouse cursor is IDC_HAND when it hovers over the non-transparent regions in the Electron window, and how it changes to IDC_IBEAM (as that's the appropriate cursor for the vscode window below) when it hovers over the transparent regions. electron/electron#1335 (comment) Unfortunately its impact on performance is probably too great for the app I'm developing. Your option 2 is probably more suitable for my case. Thanks again for the great explanation! Edit: the link has been corrected. |
Beta Was this translation helpful? Give feedback.
-
Well - in case of the demo - and assuming that the webview window has focus, there isn't much communication needed for changing the mouse cursor, because as long as the webview has focus, it's the browser alone to be in charge of changing the mouse cursor, so you don't even need to communicate with the outside for this. Option 2 would make sense if you want to use hit-testing functionality of the native side, but it would fail when elements inside the browser can overlap controls on the outside - which you can't know from outside code. Last: Use web messaging for communication between browser and outside world (like PostWebMessage). It's async and capable enough to even transmit pointer-move events to the outside. |
Beta Was this translation helpful? Give feedback.
-
|
Progressive Web Apps are the future. Native apps need to die. |
Beta Was this translation helpful? Give feedback.
-
C# is for lowest common denominator users too. There is no reason to use it. Look at UWP, it was so crippled and even PWAs have much more permissions. BTW, you think windows 95 PWA which i use everyday on my windows on arm laptop is not powerful than the junk which is C#'s UWP or .net maui. NAIVE. C# devs are just ignorant nothing more. |
Beta Was this translation helpful? Give feedback.
-
I am sure, Win32 can be expanded to include Android-like permission management, like access to user's files, camera or other devices. There is not need to develop new toolkits for it. There were no ACLs in Win95, and they are now along with UAC, for instance. There is no problem to implement a mobile-like permission control on top of this. |
Beta Was this translation helpful? Give feedback.
-
|
I hate Win32. I use it because Microsoft can't get their act together and build a more capable Windows API. It's antiquated and weird. We should stop building on top of it and build new stuff. |
Beta Was this translation helpful? Give feedback.
-
i hope this is satire because MS has done exactly that in the past 10 years multiple times and look at what we get now. |
Beta Was this translation helpful? Give feedback.
-
|
That's just not true, Microsoft have doubled down on Win32 as a solution, providing CsWin32 because they don't know how to provide a modern replacement. UWP was the closest they got. I know it had problems, but there were a lot of good ideas. For example, where is the CoreWindow API's today? UWP had a core-window, what have they provided to replace that? Nothing. I hope WindowsAppSDK can one day at least deliver an improved API - but it's still built on top of Win32 AFAICT. UWP worked on XBox, what have they replaced that with? Oh right, Win32 + GDK. See how they are going backwards in someways. |
Beta Was this translation helpful? Give feedback.
-
|
I wish somebody would lock this thread. |
Beta Was this translation helpful? Give feedback.
-
|
@tstndeemkssz Given your very confidently stated incorrect assertions about many things in this thread I'm pretty sure you are just trolling but to address a few:
|
Beta Was this translation helpful? Give feedback.
-
|
@tstndeemkssz Just FYI, visiting google.com and not even doing a search yet (cache disabled for this request):
Actually doing a search after (this is all in addition to the previous counts, cache enabled for this request):
Loading a full Uno Platform WASM / C# / XAML application I developed (cache disabled for this request) with fairly substantial custom font and icon assets, with no further significant transfers required to use the app after that since it is all preloaded (other than small API data requests in the KBs range):
And I haven't even started size-optimizing yet because it is so low-priority. The icon library I'm using has like 5000 icons, and I use maybe 50 of them. Using Uno Platform means I write C# / XAML WinUI code and effectively get cross-compiled native Android / iOS / Windows (WinUI3) / Linux / MacOS app support for "free" which utilizes native controls and thus things like TextBoxes retain expected platform-specific native behavior, plus a WASM web version (PWA enabled, btw, since you seem to love PWAs so much) people can use if they don't want to install the native app. So....pretty sweet deal I would say. Why the heck would I want to wrap the WASM version of the app in a webview everywhere when I can just compile to native for every target platform effectively for free, and get direct access to APIs for each native platform as needed through built-in .NET bindings? Absolute nonsense. Native always performs better when done right. Btw something more non-trivial like visiting docs.google.com instead of a simple search textbox page like google.com, which is a closer comparison to the app above:
I think you need to re-evaluate your understanding of managed languages and runtimes. |
Beta Was this translation helpful? Give feedback.
-
afaik this is true on windows and mobile but on linux (macos too?) everything is drawn manually by uno. |
Beta Was this translation helpful? Give feedback.
-
|
@ivanjx Yes indeed. Though you have the option of using mac catalyst as the mac target. |
Beta Was this translation helpful? Give feedback.
-
|
@softworkz in Winforms you can have subpixel rendering, of course, and it is exactly my point. You cannot have it in XAML. And regarding customizability, try to re-style the XAML-based Win11 taskbar or Settings app to look like XP or Win2000. At best, you can get the same colors, but nothing more. |
Beta Was this translation helpful? Give feedback.
-
|
Crazy: Now I'm one of less than a handful of non-MS people with a PR gotten merged in this repository in the past 2 years. And yes - it's ridiculous. Feel free to joke about it! I wish they would have merged the relevant ones instead (#9248 & #9224) |
Beta Was this translation helpful? Give feedback.
-
|
Very solid community PR merge though 😆😆😆 |
Beta Was this translation helpful? Give feedback.
-
|
I've raised a discussion over at the Windows App SDK about the state of this repository: Our stack is mainly WPF with a few newer WinUI apps. Our clients have expressed concern at several long standing issues so we are now looking at moving backwards (if you can believe that). Hopefully we as a community can get an answer from the WASDK because it looks like this repository is abandoned. It's been months since there was any official update from Microsoft about the direction this project was taking and nothing has been done to address the raised concerns. EDIT: Guys I'm not going to respond to comments individually; I'm not trying to make this religious, I have nothing against WinForms or WPF - we have multiple apps written on those platforms. My concern for WinUI is simply that 1) we have significant investment and 2) we have followed Microsoft's guidance since the release of Win8 - Metro -> UWP -> WinUI + WASDK. It feels like this project is completely abandoned now, but I hope I am wrong. |
Beta Was this translation helpful? Give feedback.
-
|
@knightmeister are you planning to use dotnet macios (previously known as xamarin.mac and xamarin.ios) for the ipad app? if thats the case are you using storyboard or pure c# code for the view? |
Beta Was this translation helpful? Give feedback.
-
|
WinUI is definitely not the native stack for Windows. Of widely used programs, only Watsapp, I think, uses WinUI (or some of its predecessors). The native stack for Windows is Winforms and (to a lesser degree), WPF. |
Beta Was this translation helpful? Give feedback.
-
WPF isn't that look dated I guess? WPF Gallery looks decent enough for me |
Beta Was this translation helpful? Give feedback.
-
@ivanjx One of our older apps started life as Xamarin.Mac and used |
Beta Was this translation helpful? Give feedback.
-
|
here is modern take on WPF EDIT: FYI Microsoft is behind the scenes implementing WPFUI library into .NET 9 and .NET 10 together with its author. It still in progress. |
Beta Was this translation helpful? Give feedback.
-
|
In the meanwhile, yet another stellar native app is abandoning Windows native experience: https://www.neowin.net/news/whatsapp-for-windows-is-ditching-uwp-for-a-web-app/. Now, this is outright a tragedy. Years ago Microsoft used to have evangelists who would work hard to persuade developers to use Windows native technologies. Not only these days are gone. The mere progress and communication on Windows native app development is pathetic. I am now starting a new client for our enterprise app, and I will do it with WinUI. But. We based the solution on a very solid MVVM architecture, and now, if we need to switch to WPF or even Blazor, most of the app logic and behavior will remain intact. Can't trust WASDK, not yet. Ah, and we dearly miss TableView. I know there are serviceable third-party alternatives, but none fits our requirements: slim, fast, no editing, no bells and whistles, even no sorting and grouping. Just a plain grid with some interaction and styling exposed. All the rest must be done via the VM, not rely on the grid to create its internal VM and do the heavy lifting there. |
Beta Was this translation helpful? Give feedback.
-
|
And I can't care less about the lack of designer. Honestly, Xaml designers encourage bad practices. What we need is a Design-time Live View, so that you can immediately see what your form's going to look like. Live Preview is a nice feature, but I should be able to do this while coding. |
Beta Was this translation helpful? Give feedback.
-
|
Just FYI, we ditched WinUI3 entirely, even for windows apps, and just use Uno 6 now with the new Skia renderer for all targets. Much nicer experience, UIs are smooth as butter, code is directly compatible with WinUI3 and their team is super responsive to any issues you may have. |
Beta Was this translation helpful? Give feedback.
-
|
Neither PWA, nor UWP are native. The only native subsystem is Win32. |
Beta Was this translation helpful? Give feedback.
-
|
@suypdolpao , and the world is wrong. Companies save on developer costs, and doom usability and user experience. PWA's are just outright a wrong approach, a total inner platform antipattern. While it is fine to have your UI in HTML/JS, having your state management in JS is as bad as it can get. Well, enjoy your chat app consuming 800 GB of RAM. |
Beta Was this translation helpful? Give feedback.
-
If you don't want a walled garden, then Flutter or Uno are great approaches to writing non-web apps. P.S. Yeah, nitpicking on typos is a way to win. |
Beta Was this translation helpful? Give feedback.
-
|
This page has become so long and resource intensive that my 9950x stutters when typing. But winui3 team does not seem to care |
Beta Was this translation helpful? Give feedback.
-
|
I genuinely think for Windows native development to one should look again at Delphi or Lazarus/FreePascal. MS certainly can't care less about performant native applications. A whole browser engine to run a simple client app? Sigh... The industry knew better in the 90's with amazing IDE support and efficiency. WinUI is and always will be a mess. Can't even support plain flat c code. |
Beta Was this translation helpful? Give feedback.
-
|
What do you think about WinForms? Is it that bad? I am sure it is better than interpreted javascript in web apps. |
Beta Was this translation helpful? Give feedback.
-
it is tough to make winforms app look beautiful but not impossible. MS should have just focused on winforms/win32 rather than creating a new gui framework on each windows releases. |
Beta Was this translation helpful? Give feedback.
-
|
So all those support PWA / move to web, should also love below idea. That running or pin PWA with smaller browser.
Who tag chromium team to do 2) option, that option i think is the best. (You still using HTML while the code never run inside your local). Safer than App Sandbox etc. |
Beta Was this translation helpful? Give feedback.
-
That sounds like qt qml |
Beta Was this translation helpful? Give feedback.
-
|
using skia to render stuff kills accessibility |
Beta Was this translation helpful? Give feedback.
-
Yes that's a thing with all those newer stateless GUI's. Accessibility? O we didn't think of that yet... keyboard nav? |
Beta Was this translation helpful? Give feedback.
-
|
MS should just make a native fast UI control library that is accessible from plain C and supports KISS design templates and supports accessibility and all known concepts of plain old win32 controls. It should have an advanced grid and navigation controls. Design should be consistent and used everywhere in Windows and Office. Apple could do it with their choice of language objc... MS has no great engineers left it seems. Massive company and every single modern product is over engineered and slow and unstable and inconsistent. Sad to see it happen. |
Beta Was this translation helpful? Give feedback.
-
|
WinRT and WinUI are a strange Frankenstein. Microsoft created a system with a split-personality that wants to be .NET but also wants to be native. As a result, it does not support any programming language well. They copied many architectural ideas from .NET: metadata, interfaces, async programming, runtime projections. But they did not actually use the CLR or IL, choosing instead to define a new ABI-based system with its own metadata format (WinMD) and COM-like object model. This misguided design serves no one well. C# devs are forced to call into a foreign ABI and pay for interop costs, losing native .NET performance features. And C++ devs are forced to write .NET-style interfaces with awkward winrt::implements<> hierarchies, bending over backward to use a model that’s natural in C#, but unidiomatic with C++. With C++, this leads to things like: WinRT and WinUI = The Runtime Nobody Wanted. C++ feels like writing .NET with training wheels. It's clunky, unidiomatic, and template-unfriendly. C# looks natural, but incurs interop and performance cost. Async is awkward and perf is worse than managed. Microsoft should have either stayed with native C-like APIs or they should have moved the OS to support .NET directly and pushed .NET languages. And that matches what I see people recommending: If you are doing C/C++, stay with Win32, Direct2D, and DirectComposition. If you are doing C#, stay with WPF. Creating a .NET-like system, but an incompatible one that favors native over managed code by introducing a new, incompatible ABI that is awkward for native code to use, was clearly a misstep. And it's sad that Microsoft is left having to support this Frankenstein. What a mess. |
Beta Was this translation helpful? Give feedback.
-
|
@goowy-maker The time to ask Microsoft to focus on one programming language was like 1998. That ship has sailed a long time ago. Like it or not, there are massive communities for all different languages and to Microsoft those are customers. So Microsoft has chosen to meet them where they are (hence the MIDL+WinMD solution to project a runtime API to different languages) |
Beta Was this translation helpful? Give feedback.
-
But isn't the point that
mean this is a fools errand? Microsoft should meet its actual addressable market of Windows developers where they are, as well as leverage the tiny amount of resources they put on this project instead of spreading it thin. The thread we are on is a debate about whether WinUI3 is dead or not, which seems to undermine the rationale for casting the net wide for other languages vs optimizing for C#. Worrying about supporting multiple languages is putting the cart before the horse. If you barely have developers writing in your base language and C++ because of missing features, bugs and flaws on both sides of the binding, why would diluting your efforts and the power in those languages be a worthy choice? What other languages have meaningful development being done in them for WinUI 3? Seems like the answer is more relevant to whether it was a good idea or not, more so than simply the mere existence of lots of developers of other languages in the world. What's the uptake? |
Beta Was this translation helpful? Give feedback.
-
|
@cdock1029 I would disagree that it's not supported well by any language. The language support isn't the issue in almost all cases, except for C++ being kinda non-idiomatic. |
Beta Was this translation helpful? Give feedback.
-
|
Yea the wording is bad on my part. I don't mean the languages aren't supported but the overall quality of the platform is not supported well partly as a function of building it for breadth not depth. Otherwise why does this thread exist? Why is WinUI3 "maybe dead" and why do many .NET devs cling to WPF instead? Beyond just being supported, what is other language usage like? I really don't know and concede I can be off base, but how much WinUI 3 Javascript or Rust or whatever development is there? Would the platform be in a better functional (and adoption by developers) state if it was optimized for C# instead of built for multiple languages..maybe the response to this is well C++ support was non-negotiable so once you go down that road other languages are supported by default so it's irrelevant. But if the goal was as you said to easily support automatically generated projections in any modern language, the value of that goal should be judged by whether it's actually happening or not and at what cost. |
Beta Was this translation helpful? Give feedback.
-
|
@cdock1029 Well as I said before, 99% of the issues aren't related to the WinRT projection tech, but rather the poor quality of the WinUI implementation itself, which could be solved if MS cared to manage the project better and put sufficient resources into it while still keeping the WinRT projections intact. |
Beta Was this translation helpful? Give feedback.
-
|
Attention, looks like great news: https://www.theregister.com/2025/08/05/microsoft_winui_open_source |
Beta Was this translation helpful? Give feedback.
-
|
We did it guys, we complained enough and it's happening! Haha 😅 |
Beta Was this translation helpful? Give feedback.
-
|
are we supposed to fix the bugs ourselves then? |
Beta Was this translation helpful? Give feedback.
-
|
Probably 😆 Time will tell if they implement any sort of reasonable community PR management so it's not all wasted effort. Hopefully the past isn't an indicator of how that will go lol. |
Beta Was this translation helpful? Give feedback.
-
|
In good news, Uno has been chomping at the bit to be able to PR fixes to the WinUI codebase since they have a WinAppSdk target option, so I imagine good things will come of this as long as they actually review and accept the PRs. |
Beta Was this translation helpful? Give feedback.
-
|
I feel like other internal teams like the MAUI team would be more likely to contribute PRs after this is all done as well instead of just trying to work around issues. |
Beta Was this translation helpful? Give feedback.
-
|
This is a very informative discussion. I spent over an hour reading it and some linked contents. |
Beta Was this translation helpful? Give feedback.
-
|
I've been reading through this as well, and I still do have hope. I have been working with WinUI 3 for a while, and if used in C#, I very much like it a lot. The UI is beautiful out of the box, making custom controls is pretty easy, and it feels performant. I currently do not know if I should continue working with WinUI 3, or switch to something else. I do not want to work on something just for the framework to be killed off at some point :/ The framework feels like it is in a state of limbo, with an uncertain future only known to microsoft themselves. I truly hope WinUI 3 and WASDK get the love it deserves from the open source community, when the oppertunity arises. Who knows, maybe it will end up as a WPF 2.0 at some point 🤷 :) |
Beta Was this translation helpful? Give feedback.
-
|
I tried the Copilot WinUI app and it is absolutely unusable on a laptop. It takes the whole screen area, without possibility to shrink the window, shows gigantic and ugly fonts (without subpixel smoothing and not following the Windows system settings), and is apparently intended for phones and touchscreen, definitely not for a desktop or (especially) laptop. The Copilot PWA is so much better! |
Beta Was this translation helpful? Give feedback.
-
It still gives some clue to whether microsoft is internally dogfeeding the WinUI 3 project. Internal teams making new projects using it does suggest exactly that. I just hope that WinUI 3 will get better, now with internal and external pressure increasing. |
Beta Was this translation helpful? Give feedback.
-
|
I am a die-hard Windows user. I never touch a Mac. I started developing for Windows with Microsoft QuickC in 1992, before many here were born. Microsoft was the untouchable king of software development tools not too long ago (nothing was remotely close to Visual Studio). It is no longer the case. I've witnessed Android Studio evolving from a clumsy and glitchy IDE to a powerful tool that surpasses VS, largely because everything in it just works. It is very sad for me to see one blunder after another from Microsoft. Windows Phone is still the most beautiful mobile OS to me. If Microsoft had not killed it due to its worst app store, I would still enjoy using a WP phone daily. |
Beta Was this translation helpful? Give feedback.
-
You know, maybe the move to open source is exactly that, an exit strategy to move on to the web. Native developers get to fulfill their needs themselves while Microsoft goes all in on the cloud. |
Beta Was this translation helpful? Give feedback.
-
|
There were rumors that Microsoft wanted to pass Windows to Amazon, but that failed, and they do not want it. |
Beta Was this translation helpful? Give feedback.
-
|
I do not know about you, but I will continue to work on UWP. Since it got back to VS installer and it is in great shape at least with support all Windows SDK. It is like WPF done and good. Works better than any revision of Win UI 3. I think Microsoft rushed too much into Win UI 3 where it was clearly not stable and not usable. Little bit like with Windows 8 on desktop, what was without a thought. |
Beta Was this translation helpful? Give feedback.
-
I've given you all the pointers you need to get going (without msixupload files). If you are unable or unwilling to understand and try them out, I can't help you, I'm afraid. |
Beta Was this translation helpful? Give feedback.
-
|
Just in case you did not read the issue, I took a screenshot of it as follows: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
It's also easy to create an msixbundle manually: md bundledir
copy "xxxx\source_x64.msix" bundledir\
copy "yyyy\source_arm64.msix" bundledir\
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\makeappx.exe" bundle /d bundledir /bv 1.2.3.4 /p "out.msixbundle" |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Well I'm confused now since MS added another new WPF gallery. So it's hard to tell which native platform should we stick to, WPF or WinUI3? |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Yesterday I made a post (Great News: All Bugs Will be Fixed In the Year 2041) which was meant to be a somewhat funny complaint about the lack of activity in terms of development progress and dealing with user issues submitted here.
Then I made a comparison of activity between WinUI3 and MAUI and those figures are quite revealing when thinking about it:
How can it be possible that MS is investing 20 times more effort into MAUI than into WinUI3 - the new and designated primary UI technology for Windows desktop?
Simple answer: It can't. It can only be possible in case when WinUI3 is no longer the "designated primary UI technology for Windows desktop".
Now I'm shocked to realize that it's way more serious than I thought as so many details suddenly fit together and make sense when being viewed in the light of that premise.
It all fits together
Smaller Bits
Xbox Development
=> but Xbox is not dead. So the must be something for Xbox which is not WinUI3
Cpp/WinRT in Maintenance Mode
as noted by @pjmlp (thanks!):
Component Vendors
DevExpress are offering a few free components but these haven't been updated since mid-2022.
Their blog entries about WinUI3 stopped in mid-2022 as well (https://search.devexpress.com/?m=Web&q=winui3)
They probably know already about the end of WinUI3.
Timely Coincidence
Wasn't it at the same time (2022) that WinUI3 development had started to be driven down?
XAML Islands as a WinUI3 Exit Strategy
When looking at the changes that were made during the past year, then there's only one area where significant work has been put into: XAML Islands. Even though it had been requested by users earlier, it's not a most-wanted feature, but still, MS picked exactly that part as the one major subject of work.
XAML Islands allows to integrate WinUI3 content as "islands" when using other UI frameworks. Why is this so important? Who needs this other than a few with very specific use cases?
When customers want to modernize their applications, who would start by implementing something in WinUI3 which is then shown like a control/window within a WPF or WinForms app? Normally, such migrations would rather go the other way round: starting with a new application framework and subsequently migrating legacy components. But that's what is not being worked: There's nothing like a hWnd-Panel (which had also been requested by users).
Bottom line: When establishing a new framework for app development, then it's usually crucial to provide ways for developers to integrate legacy components into the new framewrok to allow subsequent migration, but not the other way round. Provisioning for the other direction only (and also as the only major change) can only mean that this is the end of the road for WinUI3, and XAML Islands are just implemented to soften the impact for affected developers enabling a life-after-death existence for WinUI3 components.
MS, when did you plan to make the RIP announcement?
And what will be the replacement?
Beta Was this translation helpful? Give feedback.
All reactions