Totally agree with previous comments about WPF having a steep learning curve. We recently released our photo-tagging application called Tag That Photo. It's currently available for Windows and built on the WPF platform (Mac client coming in future). It detects & recognizes faces in user's local photo collections, allowing them to tag people, add keywords and location data to the images. All the data can be written back to the image metadata for import into other photo editing tools. Unlike many other face-recognition platforms out there, everything is executed locally so user's photos stay private.

Prior to creating Tag That Photo, we had little experience with the WPF beyond simple demo type applications. Of course we've come a long way over the course of development but it certainly hasn't been easy. We have extensive experience with many other UI frameworks such as WinForms, Android / iOS as well as various web frameworks, and I think it's safe to say that once you wrap your head around it, the WPF has the slickest architecture. The team that designed this really knew what they were doing. It has this "peeling-the-onion" mentality to it where it's simple to implement straight-forward use-cases but if you want lower-level control of essentially every aspect of rendering, binding, input handling etc it's all exposed for you.

In case you want to see the final product: https://www.tagthatphoto.com

The steep learning curve is worth it because most of the paradigms of WPF are transferable to other frameworks. It's my opinion that learning it well will actually make you a more organized programmer in terms of your architectural chops.

Its heavy use of binding, aspect oriented programming, dependency injection, cascading styling dictionaries, converters etc. are heavily leaned upon in a number of other UI frameworks. Once you understand how to organise these paradigms properly, you'll find a lot of other frameworks far easier to migrate to.

It's well worth learning, even if it's just as a transitory learning mechanism. I'm a big fan of learning frameworks that change your way of thinking and reduce the learning curve of other technologies. It's not for the feint of heart though - if you've never learned architecture to a level where you can separate your UI concerns from your logic properly and learned how to inject function into your UI from your viewmodel, there are some hard concepts to wrap your head around - especially when it comes to debugging - if you don't separate your concerns properly, it will make testing and debugging a bitch.

There are a lot of "Oh wow! I never thought about it like that!" moments of realization on the curve - rather like that moment when Scotty realizes that he never considered that it was space that was moving in his transporter algorithms.

Yeah, I agree completely. WPF may not be as "pick up and run" as WinForms was, and perhaps some of that "pick up and run" of WinForms was hold-over from VB6, or being young enough to spend tons of time on it. But once I stopped just trying to "hack" at it and started actually reading the documentation, I really came to appreciate WPF, how it's put together, how it all works. Wish I had gotten on board with it when it first came out, rather than putting it off until just a few years ago.

I think just in general databinding has a steeper learning curve then the code based update approach. Kind of how Angular has a much steeper learning curve than j-query.

I’ve been looking for something exactly like this since the demise of Picasa. Just checked out the website, but I can’t figure out your pricing. Is it a one time purchase or subscription? How much does it cost? I’m not going to sign up for a free trial unless I know the pricing structure.

It is a annual subscription based model, but you are free to cancel at any time.

Check out the plans page for more info on the pricing. https://tagthatphoto.com/plans/

When I had the chance to use it seriously many years ago, what I found about WPF is that once you got the hang of it, you could literally look at any sufficiently complex application UI and know immediately how to build it using WPF in record time.

It's that composable.

Agreed. People are complaining about it in this thread, but I thought it was almost on par with Cocoa, overall. Just like Cocoa, you have to "drink the Kool-aid" a bit and decide to structure your application to match the framework rather than adapt the framework to match your preconceived notion of how your application should be structured. Once you did, You could get a lot of work done.

Personally think that these frameworks, like WPF and Cocoa, are still easier than working with Angular/React/Vue, but TBH that might be a reflection of my weaknesses with web development more than anything else. XAML is a bit of a mess but compares favorably to HTML+CSS, and XAML is almost as good as Interface Builder in my mind. The MVVM approach in WPF could be improved but it makes sense.

WPF definitely requires "drinking the Kool-aid". For WinForms Devs, it might be tough to swallow, but it's good medicine. The state of WinForms development before was not sustainable and incredibly challenging with large applications.

Having tried to develop a WPF app like a WinForms app, it is incredibly tedious because it's not what WPF was designed to do. Drinking the Kool-aid and working within the confines of how WPF was designed to work makes a lot of things significantly easier, but the trade off is having to explicitly set up view models, use data binding, and find alternatives to doing everything in code behind.

IMHO, the biggest challenge was dealing with the databinding ecosystem, which is incredibly powerful, but also complex, opaque, verbose, and tedious. There is practically no debugging of databinding, which is incredibly frustrating. It's hard to figure out why it doesn't work or why you don't get what you expect to get in whatever is actually being called.

Whether it was old winforms databinding or various js databinding approaches on the front end, its always been fairly straight forward to get what I needed. WPF always seems like it's jumping through hoops for things that should just work. I'm sure there's a lot of logic behind how WPF's databinding actually works for it to be able to support all the various situations that it does, but, for me, it's never been very clear, and I've wasted countless hours trying to find and debug the right databinding syntax only to have it still not work and have to resort to a less elegant/hacky way of achieving the result that I'm looking for.

I still don’t understand why instead of evolving WPF MS keeps cranking out similar but incompatible XAML frameworks like Silverlight, WinRT and UWP. If they had stuck to WPF and made the syntax less verbose and easier to understand and fixed some other warts WPF would be a kick ass development tool.

Because WPF is .NET based and internal Microsoft teams with C++ codebases (like Windows and Office) didn't want to take a dependency on .NET (or rather they tried with Longhorn and couldn't make it work).

That's a big issue but it doesn't explain why instead of developing WPF they released WinRT and UWP.

The purpose of WinRT was to avoid having to depend on .NET. Developing WPF to fix this would have meant rewriting the whole thing in C++, which is what Silverlight/WinUI sort of was, but I agree they dropped the ball on compatibility and migration

I think it was more a thing of those teams torpedoing Longhorn efforts than actually trying.

To be fair, UWP and WPF aren't that dissimilar (and both are XAML), with differences in the readymade UI elements and a stricter subset of the binding markup.

They are dissimilar enough to make a port of a large app very difficult.

What evolutions are you looking for that aren't covered in their .NET Core/.NET 5 plan?

Debugging data binding is hard. There could be a tighter coupling and type safety between view model and view. MVVM could be better integrated. The syntax generally could be simplified (MVC did this when they introduced Razor). There is a lot of room for improvement. The foundation is very good but very hard to learn and you need a ton of obscure little tricks.

The .NET 5 doesn’t address any of these. They do a lot of good stuff for server side development but the story for desktop development is bad.

Agree. That's why we have this for Avalonia XAML debugging (XAML is compiled to IL) https://www.youtube.com/watch?v=9VtwwEL1SJM

I mentioned this elsewhere in the thread but you can get compile time warnings and autocomplete on data binding by adding a design time view model.

To some degree yes but it really doesn't work well for complex cases. During runtime they spit out data binding warnings too but these are hard to trap. at least I haven't been able to figure it out.

A Windows UI framework that's modern and performant (so not WPF), at least somewhat competitive in flexibility and expressiveness and tooling with HTML/CSS (not WPF or UWP), and does not have a sandbox or mobile-style process lifecycle chained to its ankle (so not UWP).

I'd throw xplat in there, but I think I'm already asking for too much.

Windows UI platform team recently posted their roadmap for the platform https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... and they have a GitHub issue thread requesting comment on the roadmap https://github.com/microsoft/microsoft-ui-xaml/issues/717 , you might want to take a look and post your thoughts

Don't mean to be disrespectful, but that sounds an awful lot like the standard corporate non-reply of "Thank you for your feedback requesting the dead-obvious thing that everyone wants and that we know everyone wants but we are not doing for undisclosed internal reasons. Your feedback is interesting and novel and will be read and carefully considered if you will just put it right here into >/dev/null. Thanks for your time!"

You talked yourself out of trying.

Is it different if you send your comments to /dev/null or if they do? I think it is. In one scenario you at least gave it a try.

From what I have seen, the WinUI story is a complete shitshow[1]. Apparently they realized that tying it directly to Windows releases was a bad idea, and want to packagize it into NuGet assemblies, but kind of can't. They appear to be trying to distance themselves from even calling it UWP anymore, which I suppose makes sense, because it was dead-on-arrival and never gained any momentum.

Windows 8 is still casting a long shadow of half-baked bad ideas.

[1] https://www.sharpgis.net/post/2019/05/14/The-future-UWP

It's hard to trust their roadmaps. They always look good but get abandoned every few years.

After using Cocoa for about 10 years and React for maybe 1-2 years, I'd say that React is way easier for visual customization and hierarchy. Cocoa's hierarchy is more efficient but at a cost of being more verbose and tedious. But Cocoa was never meant to be very easy to visually customize, since part of the Apple Way ™ is that everything looks and works the same, which was probably a reaction to the over-customization of the 90s and early 2000s, but tends to go against the grain in modern UI where every application has its own branded UI that basically requires the composeability and simplicity of HTML + CSS.

Edit: also, nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app)

> nobody wants or uses native desktop apps anymore, so that's a big plus for React (either via Electron or just plain web app)

The customers I served during the last four years beg otherwise.

Like them there are plenty of European companies willing to pay for native desktop apps.

And I mean green field development, not maintenance.

Not everyone has business cases that can stuff into Web or mobile phones.

Compared to winforms, WPF has an incredibly steep learning curve. Working with it was always painful to me. The vector graphics architecture they mention makes it even harder.

While it's rich capabilities enable you to implement everything you can dream of, doesn't the same hold for JS desktop apps? (+ they are cross platform)

I don't see the use case anymore...

We developed a number of applications on it, but found it to be very verbose, quite brittle and needlessly complex.

It is brittle because XAML itself is a compiled language without the ability to step through or debug well, which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages.

it is complex because the language is supposed to be an object tree building mechanism and thus needs to be quite generic.

It is verbose because of the underlying abstracted data model. e.g dependency properties etc.

Compared to HTML, where the 'evolutionary' pressure to create a workable compromise is much higher.

I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.

> which means runtime errors in the object tree usually causes the entire app to crash with very abstract error messages.

This is absolutely untrue. Xaml errors can be caught like any other error, and most errors get swallowed rather than crash the application (which can cause some debugging headaches when things aren't rendering as you expect).

> I used to think XAML could be better if architected well, but the missing ecosystem and usage around it made it so, that HTML was and still is massively more productive.

I don't think html is massively more productive. I'm not even saying that WPF is so much better, but start debugging any reasonably large react application and you're just as likely to get into an unproductive quagmire.

The sad thing is that XAML could be great if they just had put a little more work into it.

Modern js frameworks makes mvvm/similar quite pleasant. Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out).

On the other hand, the layout model of WPF is a lot easier than mastering html+css.

JS desktop apps still mostly don't work without embedding a browser like electron and that ranges from annoying (e.g. for size/memory reasons) to impossible (for things like a plugin where you have a constrained environment, need to launch instantly etc).

The middle ground is desktop js using system browsers, but it's pretty painful to do too.

> On the other hand, the layout model of WPF is a lot easier than mastering html+css

Thank you. I've never been able to figure out if web layout is as terrible as it seems, or if I'm just missing something.

Once you spend the 20 minutes to learn the WPF layout algorithm, you can reason about why every element is located where it is, down to the pixel. To get there with HTML/CSS, I feel like I would have to memorize and recall a huge list of ad-hoc rules, and their combinatorial interactions. Usually I just give up and accept the mysterious 3-pixel gaps that seem to crop up randomly, and I don't even attempt complex layouts.

WPF never quite made the leap from data-binding and MVVM to a component-based + state-management architecture like React&friends. A consequence of that is a hairy overcomplicated mess of a binding system that's full of footguns. But it was still ahead of its time - that one last step would have made it amazing.

They could easily have done this but instead chose to make several new frameworks that didn’t improve anything. Very sad. Now MS has several mediocre not well maintained frameworks instead of a really good one. The constant churn also killed off a lot of open source efforts

This isn't my area of expertise. What are some of the other MS frameworks or OSS projects you refer to?

WPF started XAML, then came Silverlight, WinRT and UWP. They are superficially similar but under the hood the code is quite different and each has its own set of weird limitations so you can't just reuse code. Also, in the case of WinRT and I think also UWP the new framework had less features than its predecessor so in a sense it was worse and less powerful which is not a good way to convince people to port their code.

When WPF came out there were quite a few very cool open source projects that built on top of it because it's really easy to extend WPF and build components for it. But then every two or three years MS announced a new framework so most of these efforts died out. When you look at commercial third party suppliers like Developer Express they have the same component in three or four flavors. this must be a huge and expensive effort to maintain.

Those feel like they were created by orders from top management, because of some strategic decision (microsoft needed a flash alternative, or a Windows 10 store UI framework etc).

They don't feel like the product that would come if DevDiv did their best to produce a sane UI framework. They feel rushed, semi-overlapping, half-finished.

I imagine it should be possible to make just one more xaml framework which is cross platform, and much better than WPF (and it's derivatives), and much better than the js alternative (Because of deployment, not least).

I'm not sure if there is any incentive for ms to put their weight behind it however.

Hopefully that last xaml framework is avalonia, it's definitely gaining steam.

Yes. But for one of these to really take off, I think what's needed is for one of the giants to throw their weights behind it. Basically "We're betting x billions on it, so you can be sure that lots of companies will be using this tech in the decade to come".

The XAML in Avalonia is great. There is even support for XAML to IL compilation during build so you don't have any parsing overhead when running your app.

"WinRT and UWP" in this context are just two names for the same thing, though

Sort of. They were released some years from each other. WinRT was super weak and never took off and then suddenly UWP came up.

APIs were the same, just with some upgraded and new stuff

I think the various name changes have been extremely confusing and created the perception of more "resets" than actually happened at the code and API level. They dropped the ball by not bothering to have a good compatibility and migration story across WPF->Silverlight->WinUI, but since Windows 8 they've been pretty good about maintaining continuity for WinRT APIs

After trying WinRT and seeing that everything was async (WTF?) and a ton of APIs were missing I admit I stopped bothering to look any further. UWP (the UI part) is also not really a step up from WPF either.

Because any UI code that requires performance should be async and lenghty work must be done outside the main thread.

So Microsoft learned how lazy devs are and how ignoring such advises contributed to bad perception of GUI apps, e.g. Swing, and forced everyone to code the right way.

It is relatively easy to turn async code into sync, if really required.

If that was really MS's reasoning I find it risible. There are many perfectly good reasons to have synchronous IO APIs. Yes, in the wrong hands they can make for janky UIs, but then the problem is not the tool, the problem is the developer.

MS's market was full of amateur-hour developers because their platform (WP7) was weak and lagging behind, thus incapable of attracting the top tier of devs. And then they poured gasoline on that fire with a barrage of silly incentives that were ignored by pros but attracted even more beginners. Now, to put a cherry on that fine mess, they attempted to remedy their bad business decisions with a technical solution that damaged the one asset they really had - an advanced and ahead-of-the curve app-development story. One own goal after another, really.

"Keeping apps fast and fluid with asynchrony in the Windows Runtime"

https://blogs.msdn.microsoft.com/windowsappdev/2012/03/20/ke...

As for the rest, I only agree it was a big mistake not to have a proper migration path.

However, WinRT was anyway the result of Synfosky's team (aka WinDev) being on the winning side, after they won over Longhorn, so not so much .NET love was going on back then.

And we had to wait for iteractive releases of Windows 10 slowly fix all those mistakes.

There are other ways to deal with this besides async. It would have been fine if they had added async but you can’t just remove the synchronous functions and expect people to port existing apps with perfectly fine multithreaded code to async. This would be a lot of work without any payoff.

Whatever their reasoning was it was just plain dumb, heavy handed and unrealistic.

The UWP XAML flavor now has x:bind which is probably exactly what you are asking for (control bind directly to their code-behind, no DataContext and DataContext inheritance). I've heard rumors about WPF x:bind support.

> binding system that's full of footguns

Please elaborate?

> Some of the binding in WPF is quite complex, especially since you don't get proper type safety for all that effort (there is a lot of stringly typed things sticking out).

You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.

I've always thought that I ought to have learned WPF, but the reality is I don't work on significant desktop software, so when I need to build a little desktop UI, it's a quick and dirty internal tool, or at best a configuration dialog. WinForms is incredibly easy to bang out that kind of use case so it just never made any sense to put the investment in.

Maybe if Silverlight hadn't been such a deadend.

Agreed. I actually "retired" from programming when WPF was released and got into management. Framework fatigue was definitely a factor in my decision -- having to toss out a bunch of knowledge and then learn something new that provides marginal benefits.

WPF was fantastic for rich desktop applications. It makes me very happy that there is active effort from Microsoft to port it to .NET Core. If only it was cross platform...

You want Avalonia for that: https://github.com/AvaloniaUI/Avalonia

I have really high hopes for Avalonia but don't know anyone who's used it for anything other than kicking the tires. I'd love to hear of any experiences.

And I really hope MS is neglecting WPF because some key insiders are looking to hand over the desktop story to some combination of Avalonia and Blazor.

I am using it for not trivial vector drawing app [1], there is even IDE [2] written using Avalonia. Generally its really great way to write GUI applications (currently for Desktop). [1] https://github.com/wieslawsoltes/Core2D [2] https://github.com/VitalElement/AvalonStudio

They have a directive to move it to .net core - assume I assume this will make it cross-platform?

The repository for WPF for .NET Core is linked right here at the top. You can explore it yourself. It only supports Windows (there's a lot of hardcoded Win32 stuff in it). Microsoft has said they won't spend resources to support cross-platform efforts on it. They also likely wouldn't stop community forks from trying (just don't expect MSFT employees to participate during day job time), but again you can explore the repository here and get a sense of how much work it would take (a lot).

.NET Core has always had platform-specific libraries that only work on a single platform or work somewhat differently on different platforms. The UI libraries (WPF and WinForms) are just the biggest examples now of platform-specific libraries on .NET Core.

.Net Core is cross platform. So, WPF is cross plaftorm now as well

That is like saying C++ is cross platform so MFC is cross platform as well.

WPF relies on Windows specific functionality.

MFC used to be cross platform (Windows / Mac OS System 7) during the early days.

Nope, you can't build WPF apps on Mac using Visual Studio for Mac.

Actually C/C++ is cross platform that means if windows is written in C/C++ Windows is cross platform.

Reading this official Xamarin Forms document https://docs.microsoft.com/en-us/xamarin/cross-platform/desk... It's really hard to tell how the 2 offerings from Microsoft differs. It looks like Xamarin Forms is fairly mature, and supports Mac and Windows. Does anyone have production experience on both? When sould one choose one over another?

Maybe things have changed but my company did a Xamarin test two years ago and the results were horrible. They quickly went back to native apps.

It's still being worked on and is a good bit better than 2 years ago but still has a couple of warts. To be fair all of the cross platform mobile applications have quite a few warts :).

Judging from the earliest Github issues, it's been there since late 2018.

edit: As pointed out below, it looks like the title refers to recent source code commits, not the creation of the repo.

Relevant links:

https://github.com/dotnet/wpf/pull/720

https://github.com/dotnet/wpf/pull/727

The first part was System.Xaml; the next one was the build infrastructure, I think. IIRC they said that by .NET Core 3 Preview 7 they want to have WPF completely on GitHub. Until then they're probably cleaning up the code as best they can before making it open-source.

Edit: The roadmap https://github.com/dotnet/wpf/blob/master/roadmap.md has a list what's currently available and what's still missing. Looks like by now the main parts (PresentationCore, PresentationFramework) are open-sourced as well.

looking at the guts of the source code, looks like it's only just been committed ~13 hours ago. Various other things have been around for a while

Is there some simple summary somewhere about the state of GUI development on Windows? I haven't used Windows seriously for almost a decade now and my understanding was that WPF was mostly dead because it made win32 developers mad so Microsoft buried it and developed UWP and Xamarin and now nobody has a clue what to actually use. But since Windows phone is dead now everybody can go back to just using win32?

UWP and Xamarin have a lot in common with WPF. The XAML used for UI work is very similar across all three platforms and many of the controls are very similar, if not converging on the exact same. (On the one side, with XAML Islands you can even have UWP XAML inside your WPF XAML or even have UWP XAML inside your Win32 app. On the other side, a lot more of UWP controls are moving to open source up and out of Windows itself in the upcoming WinUI 3.0 library.)

Even with Windows phone "dead" and maybe you don't need Xbox or HoloLens or Surface Hub or the best experience on ARM devices, there's still a lot of advantages to UWP for GUIs (or arguably the best, most comfortable, most adaptive experience on Desktop/Tablet). There's also a lot more opportunities for "hybrid" development to migrate Win32 applications a piece at a time (instead of needing to restart form near scratch an entire Win32 application to move towards UWP), so the birds and bees are living together better now and it's no longer a "war" between Win32 and UWP. But the implication is still that all of the energy on making better Windows UI controls and experiences (such as Fluent Design System 2.0+ work) is going into UWP controls and experiences. You can get there slowly from Win32 or start fresh with UWP. If you know UWP, it should be easy enough to use Xamarin for cross-platform UI work on mobile, even with Windows phone "dead".

Even the React Native for Windows rewrite is built on top of UWP.

And from their BUILD talk, I imagine VSCode might eventually move into it, as the team had quite a few React Native vs Electron benchmarks, and was quite keen to describe all Microsoft products that are now making use of React Native.

My plan is go web as much as possible and maybe Electron :-). Windows desktop is not much fun anymore.

What would be required to make it work on Linux? Which layers would have to be reimplemented to use Linux graphical toolkit?

From what I understand, it's just a wrapper around the GDI, so implementing WPF on Linux means re-implementing the GDI.

Kitbashing this with winelib will probably be the best way to do it.

WPF is based on DirectX and does it own rendering. This may make a Linux implementation possible but I am not sure. Realistically it's probably deeply entangled with Windows.

Maybe there's a way to use hrml canvas instead?

What are the implications of this? WPF in Linux?

No. This is explicitly not a goal at the moment. This is first and foremost the effort to make it open-source and available in .NET Core 3.

They are deprecating .NET Framework and have to migrate popular application models like WinForms and WPF to .NET Core. Open Source is a by-product.

And starting later this year, .NET Core will be re-branded to ".NET" deprecating .NET Framework (on 4.8) and merging Mono into it (see Build Conference). .NET Core 4.0 will be skipped and the next version is ".NET 5" (without the Core moniker).

> and the next version is ".NET 5" (without the Core moniker).

And that single thing will eliminate years worth of confusion. About bloody time.

A nice byproduct is that it will finally convince everyone in my org that we have to go all in on migrating from "traditional .Net" to .Net "Core", on everything we do.

Also about bloody time :)

Neah, the internals are too Windows specific (Win32/DirectX) to be easely portable.

Maybe this will be the basis of a cross platform toolkit in the future , but right now MS doesn't seem to really care....

...which is really unfortunate. If they did care, it could easily lead to a renaissance of desktop apps.

Why? The Windows desktop is by a gigantic margin the most popular desktop environment. Mac and Linux combined cover perhaps a 10% or less, so if 90% coverage isn't enough for such a renaissance, why would a +~10% change that (especially considering that most of that 10% is Mac where anything except Cocoa feels weird and wrong to a very picky userbase)?

Also why would C# and WPF do that instead of the myrriads of other languages and desktop tech? WPF alone wasn't exactly popular on Windows itself.

Because once you understand it, WPF and C# is fantastic to work with. It's hands down the best UI framework i have ever worked with.

XAML makes it very easy to layout apps that scale well, and it's built-in states for controls and easy styling is very handy.

Personally i find writing XAML a step backwards when it comes to UI design and WYSIWYG tools like Lazarus which has some great layout tools are much better (and BTW personally i'd say that LCL is the best UI framework i've worked with, but it isn't without its warts - it just has less warts than anything else).

But my question was more towards how making WPF portable will create a renaissance for the desktop considering the market share it already can cover and that even among that market share isn't exactly popular, not how good WPF is.

Ever bothered using Blend?

Former Delphi / C++ Builder fanboy here.

No, isn't Blend just a separate designer though? A big plus for Lazarus (and Delphi and C++ Builder) is that the designer is integrated with the IDE and you are working with 'live' objects which extends even beyond the GUI designer but also to visual object editors. I have written several non-visual components myself that are exposed to the IDE for visual editing (and if anything, my two main issues with Lazarus is that it isn't doing enough on that front - it isn't that others are better, but Lazarus could do even more - and that the component palette cannot install components dynamically from the open projects and need to installed globally, otherwise i'd be writing even more components to be edited visually).

Yes, it is installed alongside Visual Studio.

But even Visual Studio XAML designer is relatively good. I used it is mostly.

And both do allow to work with live objects and mock data, as well, even if it isn't as clear as with Borland products.

Actually during the last 4 years, which I used to do consultancy on Windows native apps, all of the green field apps were either WPF or UWP.

The only exception was one that had to integrate with an existing Forms one.

I'm sure people are making WPF apps, but they (the apps) were always a minority and they always had issues like weird text rendering ignoring the system settings, recreated controls that look 'kinda' like the native ones but actually are a bit off, etc.

I have only seen it happen in WPF apps with "programmer art", delivered without having designers in the team.

In theory someone could use winelib or another translation layer to make a port.

So MS changed their mind not porting UI libraries to Net Core?

I don't know that they ever said they wouldn't.

Yes, until they change their mind ;)