Replies: 50 comments 385 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.
-
|
I think that the comments on the link above are the most telling:
|
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.
-
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.
-
|
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.
-
|
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.
-
|
Hmm...could that be the news: MS buying AvaloniaUI? The Avalonia site is also prominently advertising support for the component vendors' controls. I'm sure they cannot solve everything from their own side only, it requires collaboration with them, which means in turn that those parties are investing effort in this direction. |
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.
-
|
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.
-
|
If you would be right, then this would be reflected in actual code changes to WinUI3 in this regard, which don't exist. Aat least not at a scale that would match your theory. |
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.
-
|
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.
-
|
ActiPro - one of Microsoft's partners and often promoted by Microsoft, has said they won't invest in WinUI (have officially abandoned UWP as well) and instead moved their development to Avalonia and WPF :( |
Beta Was this translation helpful? Give feedback.
-
|
TBH, despite all the reassurances we get every now and then, it is very likely web widgets will take over Windows UI, and there will be some sort of winRT projection to allow COM usage for hardware device access (like we had in win8). There's little interest at Microsoft to support anything more than that, since the business model under Nadella has been Azure and cloud, and now the AI stuff. C# and dotnet both prioritise web stuff. Consumer apps can afford the performance hit of web widgets, while directx will provide the high performance where needed. There's simply no room for WinUI, or a fully managed UI framework. I personally have no idea what they are even trying to do with MAUI, since Microsoft's misguided mobile efforts are dead. |
Beta Was this translation helpful? Give feedback.
-
|
See Blazor being pushed everywhere, and regarding what you mention with Web and COM, Microsoft owns React Native support for Windows, which is what the XBox Dashboard has been rewriten, from its original WinRT implementation. |
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.
-
|
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.
-
|
Reading this is depressing. Not because I care specifically about WinUI or whatever, but just the state of desktop UI has become such a mess. And it seems like the only things we're seeing from MS are platitudes. I have an editor in my project, and that editor makes use of Now, you're probably thinking "Why not use WPF or Avalonia or etc...". The integration of WPF and Avalonia with my swap chains is a pain (I know, I've done it). And they lock me to 60 FPS, so I can't slow it down or speed it up as I'd like. I can't speak to the ability UWP or WinUI for swap chain integration, but if it's as complicated as WPF or Avalonia, then it's a non starter. Also if the basic components I need are not available (this is an open source project, I can't use DevExpress or ComponentOne to fill the gaps), then I'm out of luck and back to Windows Forms I go. I would just like a focused, and complete UI (at least as complete as Winforms) solution to work with. I want to be able to hook in a swap chain as easily as I can with a Windows Forms application and without any potential airspace issues. And I especially don't want to be spending my time writing controls in XAML that should have been there in the first place (I've experienced this with UWP and WPF - but that was admittedly a long while back). I know my use case is not important or common, but I just feel like everyone only thinks of LOB apps and those of use who do specialized things are kind of forgotten about. |
Beta Was this translation helpful? Give feedback.
-
Without SwapChainPanel, a Microsoft.UI.Composition.CompositionDrawingSurface can be used to draw transparently over WinUI3 controls (same drawing with ID2D1DeviceContext or other interfaces) |
Beta Was this translation helpful? Give feedback.
-
Yea, Microsoft.Composition is fine as long as everything is in-process. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Thank you, I replied to your PR. |
Beta Was this translation helpful? Give feedback.
-
I never said anything about XBox? And I'm sure the DX team wasn't necessarily saying not to use C# for D3D work (at least, this is what I'm taking the quote of "everyone should use C++ and the GDK" to mean). I have no desire to work on Xbox or anything other than Windows Desktop. Why should I be excluded? |
Beta Was this translation helpful? Give feedback.
-
|
Please note my new proposal to improve WinUI3 interoperability with other win32 components: #10050 |
Beta Was this translation helpful? Give feedback.
-
|
@softworkz Also I did not like the whole discussion tone, making it seem that WinUI 3 is a disaster and shame. I think MS devs deserve some respect for their job and dedication with such limited resources. @gitmixen |
Beta Was this translation helpful? Give feedback.
-
|
@float34 If microsoft cared about WinUI3 they would dogfood it more aggressively. Webdev is replacing native—investing in WinUI3 wont stop this process. |
Beta Was this translation helpful? Give feedback.
-
This is only a thing on Windows. Mac native apps are still thriving, as they do on Android and iOS. |
Beta Was this translation helpful? Give feedback.
-
|
Additionally, WPF didn't regain its ready for production status at BUILD 2024, or UWP got. NET 9 support, by accident. If anything they are the proof where the development community sees the value investing their development resources. As for the respect being throw around, where was @float34 when we were being asked to throw away our work, and rewrite from 8.0 to 8.1, 8.1 to UWP, UWP to WinUI 3, C++/CX to C++/WinRT, .NET Native to .NET 6? And if the rewrites up to UWP were at least positive, changing to a scenario were WinRT was improved, afterwards it was always been rewrites while loosing features and tooling capabilities in the process. Rewrites that are never acknowledged on communications regarding how "great " WinUI happens to be, something that only newbies would believe, those without field experience in using WinRT technology since Windows 8. Respect you say? Where was the respect when we were spending money doing rewrites after rewrites, the team apparently only has side project kind of budget, and deals like Activision Blizzard spending $68.7 billion? Certainly whoever is responsible for Windows development isn't doing their part. |
Beta Was this translation helpful? Give feedback.
-
STFU pjmlp for your C++/CX junk. .net is a mistake to begin with |
Beta Was this translation helpful? Give feedback.
-
|
First of all C++/CX has nothing to do with .NET. Secondly, I have found the only person on the planet that uses GCC without language extensions. |
Beta Was this translation helpful? Give feedback.
-
Damn. So MS tells you WinUI is the future, you bet on WinUI and then if you find something wrong with it (like, let's say the input validation support or the designer)... it is your fault that WinUI is not that good? I guess now we know why teams at MS are picking Electron over WinUI. |
Beta Was this translation helpful? Give feedback.
-
I was in the same boat a couple of months ago (especially re. Silverlight). It's not an easy decision. I even started down the WinUI path until I found most controls vendors had abandoned it. In the end I went with tried and true WPF. |
Beta Was this translation helpful? Give feedback.
-
That's Blazor Hybrid. Blazor components, hosted in each platform's WebView.
|
Beta Was this translation helpful? Give feedback.
-
|
If I never have to use HTML it will be too soon! |
Beta Was this translation helpful? Give feedback.
-
|
Blazor Hybrid feels like last hope plan for MAUI, after all the mess with Xamarin.Forms to MAUI rewrite. If I have to use Blazor, then I rather target Web browsers directly, Web widgets are as old as the Web itself and I never saw a value other than replacing the old documentation formats, or making some folks happy that Web pages are displayed on a native window, instead of opening a browser Window. Want to use native APIs with a Web GUI? A daemon or service are the way. |
Beta Was this translation helpful? Give feedback.
-
|
i feel regular users still prefer dedicated app rather than installing a daemon service that runs silently in the background. it is also far easier to integrate with the OS with something like blazor hybrid. |
Beta Was this translation helpful? Give feedback.
-
|
Why is it so hard for MS to develop a useable UI framework? |
Beta Was this translation helpful? Give feedback.
-
|
Because their mid and high level managers are not engineers and currently AI drunk. |
Beta Was this translation helpful? Give feedback.
-
|
I think: because it doesn't make them any direct money... the money is in cloud, AI, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Like leaving mobile...and now they're regretting it |
Beta Was this translation helpful? Give feedback.
-
AI is not making them any money, no company except the chip makers are making money on AI right now. |
Beta Was this translation helpful? Give feedback.
-
|
xaml is shit! |
Beta Was this translation helpful? Give feedback.
-
|
The primary concept of XAML was the separation of development and design, so that separate people can work (somewhat) independently, on the same thing: designers doing the styling and developers doing the functional implementation. The problem is that this is working (in the way as intended) only in simple cases, while in more complex cases, the intersection of these responsibilities is often getting so big that independent work is getting moot and it's rarely those simple cases where you have separate people/teams but the complex ones where you would want to do that but where it ends up that devlopers are doing design or designers need to get into development more thatn they should have to. |
Beta Was this translation helpful? Give feedback.
-
|
@HppZ you're entitled to your opinion. As far as I'm concerned, XAML does the job, but only when it works, and its WinUI 3 implementation isn't the most usable one, which is the point of this thread. |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the broader tech landscape. What has gained in popularity the past few years?
Related question: What is the single most important target platform? Which of the above DON'T support Web browser? Microsoft's apparent answer:
Looks to me like Blazor is Microsoft's "true" cross-platform answer. To me, that is a loss of decades of maturation of what makes a GUI framework "good". Especially since there are two open-source .Net-based GUI frameworks that have been shown running under WASM in browser:
I don't have an opinion on how well those run in WASM. But surely Microsoft has sufficient development muscle to examine all the existing options, and come up with a strong, well-designed, competitor to Flutter. Or port Flutter to .Net 9 and C#? ... I realize none of the above addresses the role of some "native" UI for future Windows OS. Is it practical for an OS to not have a "native" GUI? Or to put it differently, can an OS embrace one or more highly popular cross-platform GUIs, and make that (those) run really well? I don't see Microsoft winning this competition with their own technology. Probably should adapt .Net into a Rust-based technology also. I can dream... |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @mikernet in an ideal world the best would be acquire Uno (making it official, built-in in VS and with MS moneys and resources) but keep them working 100% independently as they're doing today. |
Beta Was this translation helpful? Give feedback.
-
|
@Panda-Sharp Isn't that what he's doing now? |
Beta Was this translation helpful? Give feedback.
-
|
@lindexi not sure right now he can get ALL the advantages and benefits compared to being a Microsoft branded product. |
Beta Was this translation helpful? Give feedback.
-
Three years ago I hoped for that. Seems a bit late now... |
Beta Was this translation helpful? Give feedback.
-
False. The most portable abis are Win32 ABIs. but Microsoft totally fked its own platform in the shit excuses of "security" or "all our security issues are .exe's fault or C++'s fault" |
Beta Was this translation helpful? Give feedback.
-
|
I actually find it terrifying that this post still has the needs-triage label and has not received even one official response from a member of the team. |
Beta Was this translation helpful? Give feedback.
-
|
That label has been carried over when it's been converted to a discussion. I don't thin kthat discussions are triaged, so this is probably going to stick. Then there's been a post from @gitmixen (#9417 (comment)) claiming to be from the Windows team, but the profile doesn't indicate any relationship to MS. Don't know whether it's authentic (or still involved @ms) There has also been a post by @Rinku-Stephen (#9417 (comment)), carrying the title "WinUI Developer Experience Owner". She was also part of the recent community call. Further, I have the suspicion that my post above Another Prediction: A WinUI3 Visual Designer is Coming might have caused them to confirm the advent of a designer earlier than planned (as it was rather an en-passant confirmation than a big announcement). All-in-all, I'm sure that the WinUI team is following this conversation. I hope that it has also gained some attentiion at higher levels of management, but we need to be clear that this will only ever be a one-way kind of conversation, which may or may not have an influence on future decisions, and even when it does, we'll never know or get any confirmation or response about it. Large parts of this discussion has gone way beyond the subject of WinUI/WASDK and we cannot expect the WinUI team to respond to these things. But at the level of WinUI/WASK, I think there's a common consent on these two things which need urgent and immediate action: Increase Team Staffing!Start Fixing Bugs at a Large Scale!(or at least make this repo compileable and process community PRs) |
Beta Was this translation helpful? Give feedback.
-
|
M$ seems to be not cared with WinUI 3 anymore hence the bug causing XAML autocomplete to stop working is still here. Meanwhile, .NET Maui never has this problem |
Beta Was this translation helpful? Give feedback.
-
|
Mostly because MAUI is a focused on .NET development, and WinUI happens to be the backend they use on Windows, they could switch to something else, and most of the code would remain the same. Meanwhile WinUI is built on a mix of COM and WinRT, to apparently show off the power of using C++, with the irony of not providing any Visual Tooling tooling that actually supports using C++/WinRT in any form or fashion, and making a mess out of the whole debugging experience. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Yes, but WinUI looks and feels much better and has latest apis, ui etc included so i dont have to worry about all that. they just need to do things faster and respond to this thread. WPF doesn't also support trimming |
Beta Was this translation helpful? Give feedback.
-
|
@aqibbanday What you will get from Microsoft is marketing, not the reality. For example while they brag about C++ support, they won't tell you that C++/WinRT is in maintenance, stuck in C++17 and only relevant bug fixes for the underlying WinUI and WinAppSDK implementation. You have to dig into C++/WinRT github issuse to learn that. With that in mind spend some time going around all the github repos related to WinUI, WinAppSDK, CsWinRT, C++/WinRT, and then compare what they tell, with what people in the field actually face. |
Beta Was this translation helpful? Give feedback.
-
|
I faced exactly the same question three months ago. I started down the WinUI path thinking it was the future. About a week or two in I was faced with so many problems that I reversed course and returned to WPF. |
Beta Was this translation helpful? Give feedback.
-
|
@plettb Welcome to wpf |
Beta Was this translation helpful? Give feedback.
-
Why would you consider keeping "+UWP"? "WPF in .Net 8+" is the upgrade of that. Long term support. NOTE: I don't have an opinion on "WinUI" vs "WPF". Just pointing out that staying with WPF no longer means "UWP". Maybe .Net 8 or 9 gives you better options with WPF? UPDATE I just saw your comment above. Sounds like you specifically want to hear people's experience with WinUI3. I don't have that experience; I'm focused on cross-platform (including mobile devices) solutions. That means either beating Maui into shape, or using Blazor Hybrid, or writing a native .Net 8+ app per platform and rendering custom widgets (could be Uno Platform or Avalonia UI widgets) via SkiaSharp. There is now a 4th option: using taublast's DrawnUI to render Maui controls to a SkiaSharp canvas. Pushing on all 4 of those approaches. |
Beta Was this translation helpful? Give feedback.
-
|
What junk is this WinUI3? Why not continuing WinUI2 which is WinRT and removing the sandboxing part? I produce compilers on linux for windows. I compile Windows applications to run in Wine using Clang and GCC on Linux. .NET and sandboxing are never viable options for me. Microsoft seems to be undermining Windows with C#. I don’t use Visual Studio, don’t need it, and have no intention of ever using it. Forcing packaging for a walled garden is detrimental to Windows. Why would anyone choose sandboxed Windows applications when they could simply buy a $40 Android phone from Walmart? There’s no reason to use Windows if it’s sandboxed. Why C++ is gated with nuget .net junk? Microsoft's .net is completely failure. Considering Microsoft is bitching on C++ for all their issues, then why not just stop the junk which is Visual C++? There is no reason to use msvc when clang is available. What's the point of WinUI3 when you can just go fix WinRT? WinUI3 is just another attempt to kill computing freedom. I won't be shocked Microsoft will block .exe and other operating systems on PCs for running in the future. If so I would just move to android phones and never come back. https://github.com/trcrsired/llvm-releases/releases |
Beta Was this translation helpful? Give feedback.
-
|
You wrote "Microsoft's .net is completely failure" which makes it very clear to me you have no idea what you're talking about. You're just ranting against MS and are in dire need of anger management therapy. |
Beta Was this translation helpful? Give feedback.
-
|
It's pointless to respond to this account. Like mentioned above, I tend to think that it must be some weird experiment (with or without AI) or test or something.
No activities ever before and ever after. Only the PR and the comments here (see https://github.com/search?q=commenter%3Atstndeemkssz) Whatever it is/was - it's not worth responding to . |
Beta Was this translation helpful? Give feedback.
-
|
I do not think microsoft understands why people use Windows in the first place. It is not because of some shit like Recall or Sandboxing Walled Garden junk. (In fact Microsoft's AI did so poorly that even the Wall Street butts against it and that is why Microsoft stock crashed to dust recently) People use windows because it is an open platform that allows changing operating systems and running .exe without all the walled garden and sandboxing junk. If I want sandbox, why can't I use Android, Chromebook, and iPad? They have sandboxed apps, while Windows does not have sandboxed apps. People use it because the most portable abis are Win32 ABIs, and it is the most stable even on Linux. Still, Microsoft totally fked its own platform in the shit excuses of "security" or "all our security issues are .exe's fault or C++'s fault." The most secure devices are useless. MSFT simply does a poor job on security. Of course, Microsoft wants to lock your computer down in the walled garden with App Store junk like apple does. Look at what disaster is of Windows 10/11 S mode? It is just laughable that my $39.99 sandbox phone from Walmart can compile and run Windows on Arm .exe natively while $1000 Win phone or Surface RT back then could not, despite Android being also sandboxed. No wonder Windows on Arm has such a low adoption rate: Microsoft forces the junk, which is Visual Studio, to C++. Please give up MSVC and work on Rust if you guys hate C++ so much. I am thrilled MSVC (cl.exe) dies tomorrow. It needs to die.
C# and Java literally become "native" languages when they cannot work on Android and iOS since they need to compile the runtime, which is why net Maui, Flutters, and many other "cross-platform frameworks" have the wrong idea in the first place. Languages like C++ and Rust can simply compile to things like Wasm to become virtual machine languages. The most portable technique solutions that are most widely used are Web and running windows .exe with wine. Do you see a reason for that? |
Beta Was this translation helpful? Give feedback.
-
|
This is a thread about WinUI and not for you ranting on random Microsoft tech. Please stop bringing your unfriendly and negative attitude to this thread. |
Beta Was this translation helpful? Give feedback.
-
|
@tstndeemkssz - the few valid points you might have are getting totally invalidated by all the self-contradicting nonsense around and in-between, and eventually also your tone and language, Wrting shit or fk in every second sentence doesn't emphasize but makes it just arbitrary and tiring. |
Beta Was this translation helpful? Give feedback.
-
You sound like all the anti-consumer behavior Microsoft has been engaging in for years isn't real. What about the Windows Recall Drama? Or Windows Link 365? How did Microsoft abandon Windows Phone? What about Surface RT and Windows S mode? It is no way far away from the computer being totally locked down just like iphones. You will own nothing and be happy. |
Beta Was this translation helpful? Give feedback.
-
|
If we are already in the business of blaming MS for everything, then I'd say that there can't be any doubt that they have tasked some professional trolls on destrucinng this nice little discussion by overdriving the subjects and means of the conversation, distracting, distorting until ridiculousity approaches an unbearable level where nobody wants to follow anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Just show an example of winrt without all the xaml, C# and .net junk No more nuget. No build system. No visual studio. No MSVC. No clang-cl junk. Not even Need Windows. Only clang. |
Beta Was this translation helpful? Give feedback.
-
|
You do realize that the whole reason for C++/winRT is to allow consuming winRT from non-VS toolchains, right? You're a few years late to the party. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah they had this idea once but fucked it up just as hard the mobile market, their arm hardware products and a lot others. I was so happy when the Visual C++ team once announced that they make interoperability with Clang now a priority. That did not last more then a single release and then faded away again. Compiling without MS toolchain never reached the other MS departments. At least make it useable with cmake. But right now even the Visual C++ team is completely unfunded and withdrawn from work on C++26. Just STL still working on the STL. How ironic or pathetic is this? And with the new announcement from a few tech illiterate governemnt boys that C++ shouldn't be used anymore because it is not memory safe. Maybe Visual C++ never will see the funding again. The future is dark for us old school guys who grew up with FAR pointers and Win3.1 - damit, i still have 10 years to retirement. How can i survive without selling my soul to webview in the last years of my programming life. |
Beta Was this translation helpful? Give feedback.
-
|
C++ is a living language, it will be updated to support requirements from memory safety perspective. Even today, if you stick to modern c++ you'll almost never run into buffer overrun. |
Beta Was this translation helpful? Give feedback.
-
|
From my opinion, WinUI3 is a grandson growing up, they are slowly moving most of the apps to WinUI, some core & new apps in Window 11 like MS Store, File Explorer, Calculator, Task Manager, Whatsapp Desktop look like develop using WinUI with some native UI, WinUI have a lot of issues that haven't fixed for years(can't open FolderPicker with Admin Privileges, code to open folder picker too much complicated with boilerplate code...) and with this slowly grow make us feel like WinUI is gonna dead, but I think won't, it very hard to abandon the new UI which is learn from UWP mistake & recently used to build some Window apps, for this timing it still slowly actively but I think after few years maybe WinUI will be more actively and will catch up WPF & stable to use, take a rest, give it maybe 5-10 years at least then comeback to this post, we will have the answer |
Beta Was this translation helpful? Give feedback.
-
This is a consequence of the fact that Microsoft declared UWP on life support before WinUI3 was mature enough to replace it, and still isn't. This means that UWP developers (I'm one of them, but I would also include those inside MS) have no choice but to continue to support their UWP apps. One reason I'm commenting here is that WinUI 3 should be the natural choice for UWP developers when starting new projects; however, given its current state, that's simply unrealistic. |
Beta Was this translation helpful? Give feedback.
-
|
wasdk is not just about ui. i use wasdk to save app preferences and use the secure storage api with my blazor hybrid app. |
Beta Was this translation helpful? Give feedback.
-
|
I agree, as for the inbox app not being used on a wide scale, I think it's because WinUI3 technology isn't fully mature yet, it's only since version 1.6 that I think it's more decent. But AOT support is very rough at the moment, I guess that's why they are releasing UWP with dotnet9 support, at the moment it's not stable and functional enough to fully replace UWP. the UWP compilation toolchain is too outdated again, and looking at the statement formulation it's only an intermediary transition to fully using WinUI3. Based on this phenomenon, their internal assessment is that it may take a few more years before they reach full peer-to-peer migration. Hopefully they'll focus on fixing bugs and performance issues after they patch the features, and it does appear that WinUI3 performance has made observable progress over the years. They seem to be busy adding AI related APIs at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
Five years ago, desktop development was considered to be on its way out and UWP was the "future of the Windows platform". My take on what happens is that MS restarted investing on desktop technologies after COVID made them realize that the desktop wasn't really dead, and unfortunately catching up takes time. |
Beta Was this translation helpful? Give feedback.
-
|
UWP was dead long before covid. It is very difficult to replace web at this point. |
Beta Was this translation helpful? Give feedback.
and others
-
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