search

dotnet / wpf

WPF is a .NET Core UI framework for building Windows desktop applications.
MIT License
7.05k stars 1.17k forks source link

Is this repo dead? #3904

Closed GeraudFabien closed 3 years ago

GeraudFabien commented 3 years ago

I remember asking that a few (years ago)[https://github.com/microsoft/xaml-standard/issues/230]. Seeing all the complain every time i read on somethinks about .net5 about the lack of activity here. I cannot resist to do it again.

There are no real update on master since September:

I understand that the team is focusing in WinUI or maui. And sincerly i preferred the team to work on MAUI than WPF or winform. But :

To be clear i don't ask for more support i ask to know what's going on. Just be clear with the community. Just update the readme to point to WinUI and Lock the repo if you don't want new issue. Just update the readme and do a blog post.

We will add more tests in 2019 and 2020, however, it will be a progressive process.

...

Symbai commented 3 years ago

Unofficially yes. Officially its the same as .NET Framework: "not dead". Which means, its dead in the way of no further development or improvements will be made but they are afraid of calling it "dead". If you see the commits over 1 year its mostly updating sub packages and changes from other repos.

Several month ago we heard video interviews that the WPF team should have dedicated working hours on doing reviews. Looking at pull requests being not reviewed for over a year now proofs the opposite.

Now you can say this might be because of WinUI or MAUI. But what about the, even more legacy, Winforms repo then? Its extremely active, always has been since its open sourced. My personal guess is that its because this repo is not maintained by the original WPF team. But whatever the real reason is, we will never hear a single official word to it.

Your best choice is doing the repo survey again and again and again and hope that your frustration will be heard by someone being responsible and willing to make a change.

pjmlp commented 3 years ago

@Symbai The real reason was already communicated on community calls over on YouTube. The team was merged with WinUI and created from zero, apparently everyone from the original team is gone, and the new team is very resource constrained so they don't manage to deliver more than a couple of fixes.

Now we can complain that instead of doing WPF, WinUI, MAUI, Blazor on Electron (what a bad idea!) they should focus on just having one UI-vnext framework, but after UWP failure, they don't seem to be able to decide what to do, each group talks differently about the "vision".

Symbai commented 3 years ago

apparently everyone from the original team is gone, and the new team is very resource constrained so they don't manage to deliver more than a couple of fixes.

This only shows how extremely bad this decision was. Why taking over such a huge and extremely popular project when you have absolutely no time to deal with it?!

  1. More devs are using WPF than Winforms and especially than UWP and very very especially than Xamarin (on Windows desktop). So WPF is No. 1 for C# Windows desktop UI development. And WinUI is far, very far away from being a replacement. Its even behind UWP!
  2. Why moving WPF to a completely new, possibly also non-C# experienced (WinUI comes from C++ I believe), team? Which
  3. Is absolutely busy and unable to do anything more to this project

Nobody here complains about they not focusing on one UI-vNext framework. Other UI frameworks are kinda irrelevant. What people here complains about is the fact that they are not working together with this community. They are completely ignoring pull requests, even very very simple pull requests. They are not answering to questions nor issues. And after people have complained, they then told us

  1. Its only because they are building up test enviroments, after they are finished they will start reviewing pull request. So we believed and patiently waited. Now after they built them they are still ignoring the whole community.
  2. After we raised our words again, we were told that things will change. The team now would have dedicated working hours just to review pull requests. Yeah but no... the same pull requests made since WPF was open sourced are still not reviewed. Not. Even. A. Single. Word. On. Them.

But in the end we're driving around in circles. As long as this repo won't get a dedicated C# experienced team, it's just dead and the reason doesn't matter. The community cannot help. And developers don't have an alternative. MAUI is just on paper, WinUI is in unstable preview that brings only UWP wrappers currently. And Winforms is legacy. It is just as it it. But I'm not holding myself back to show my frustration about this situation because its the only thing I can do. And while I am repeating myself, Microsoft is known to fell terrible decisions but also Microsoft is also partly willing to learn and listen to feedback, when the feedback is loud enough.

ClosetBugSlayer commented 3 years ago

Maintaining WPF is objectively the right choice for the company. The trick is to figure out the politics behind it. Remember when Steve Sinofsky was the hired hit man for delivering the blow against WPF/Silverlight? Remember when they were cruelly taunting the XAML community that everything would be done in HTML and JavaScript? It was totally un-technical, un-necessary, and un-called for.

There is something about WPF that very bad people don't like and that is exactly why it should be pushed harder than ever. I bet Google is trying to take over the entire desktop with Chromium and I bet the brass at Microsoft are colluding in a way that deserves antitrust attention. I bet WinUI goes absolutely nowhere, just like acrylic "material theme". It's a red herring. YAWN.

Thaval commented 3 years ago

This is frustrating...... developing multiple UI frameworks and leaving the good ones behind. Always start from scratch, go ahead Microsoft..

verelpode commented 3 years ago

@Thaval -- I agree. It is very frustrating. Unfortunately it represents management mistakes. It's a well-known classic management mistake to "throw the baby out with the bathwater" and start again from scratch. This strategy only occasionally succeeds. Usually this strategy results in failure, and failure is precisely what happened with WinUI formerly part of UWP formerly WinRT formerly Windows Phone 8. Catastrophic failure. Unfortunately UWP was a disaster of mismanagement that caused tens of millions of dollars of loss for Microsoft.

Basically the incorrect thinking was along the lines of:

"WPF is imperfect or does not support goal X, and we really need goal X, therefore we'll throw WPF in the trashcan and start again from scratch. Alternatively we could improve/extend WPF, and make a new version of WPF with better touchscreen features, but... NAHHH... let's throw WPF in the trashcan and start again from nothing. We estimate it'll take only 6-12 months to get back up to the same standard as WPF."

Unfortunately, 9 years later, WinUI is still not better than WPF in every area. The latest version of WinUI has made big progress but the full parity with WPF has still not arrived after so many years. It's very frustrating. This is precisely the reason why companies should not "throw the baby out with the bathwater" and start again from scratch.

The pace of development of WinUI has been excruciatingly slow. Sadly WinUI's pace has been approx 3-4 times slower than WPF's pace of development was. What's the explanation for WinUI being so slowly developed? Weak software engineers? No. Those are excellent software engineers working on WinUI. However, I know from my own experiences and observations, even when you have excellent software engineers, the pace of development is inevitably slow when you try to write a large amount of unmanaged "native" code (C++) instead of a managed code system such as C# or Java.

I dislike Java but even Java would have been a better choice than writing WinUI in unmanaged code ("native" C++). Don't believe me? Look at Google Android -- lots of Java there (plus some C++ parts, but lots of Java).
Who was the winner? Google Android won and UWP died. That's practically the same as saying:

The outcome would've been different if the competition was Java versus C#, but sadly Microsoft chose to go with Java versus C++, and so Google Android won, because Microsoft's unmanaged code strategy was a strategy that never had any chance of winning. UWP was really just such a terrible choice of strategy -- clearly you can't win when you:

  1. Throw everything in the trashcan and start again from scratch.
  2. Also, use a slower-paced development system than previously used.

Is this my opinion? NO. Actually yes it is my opinion but it didn't come from me. I share the opinion that managed code development progresses faster than native/unmanaged, but actually this opinion came from Microsoft originally, not from me. Originally Microsoft was the one who said that managed code is better and speeds up development. In my own experience, I found this to be true. Unfortunately, roughly 9 years ago, Microsoft contradicted themselves and started saying that "native code" is better and that WinRT/UWP/WinUI should be "native" code.

They decided to call it "native code" instead of their earlier term "unmanaged code", because from a marketing perspective saying "native code" sounds better than saying "unmanaged code".

Unfortunately Microsoft lost sight of their own prior opinions and wisdom -- Microsoft lost sight of the fact that "unmanaged code" sounds like a bad thing because IT IS a bad thing (except in small special cases). Unfortunately Microsoft started using odd word choices, describing it as an "upgrade" to go "native". In reality, native(unmanaged) is a downgrade. Unfortunately, even today, even after it became apparent that UWP failed so catastrophically, there are still a few Microsoft staff members going around talking as if "native" is a good thing, and saying things like "Let's upgrade it to native" -- ignoring Microsoft's own prior wisdom about the advantages of managed code over native/unmanaged code.

Think about the literal meaning of the term UNmanaged code. Unmanaged -- literally interpreted it's like saying mismanagement. UWP was mismanaged catastrophically, thus it is fitting that UWP and WinUI use "unmanaged code" AKA "native code". Ironic: Literally the failed/mismanaged plan was the plan that used unmanaged code.

So there you have it. There are a bunch of excellent staff members working on WinUI, but unfortunately WinRT/UWP was a "no-win scenario" that put these excellent staff members in a difficult impossible situation.

verelpode commented 3 years ago

So what should Microsoft do now to repair the situation? Sadly it's now far too late to switch to the correct plan. Originally the correct plan would have been to continue development of WPF, and continue using managed code, and continue using .NET Framework (in both desktop and mobile devices). Unfortunately the correct plan was not executed.

Everyone who posted in this issue (plus many other silent developers) want to see development of new versions of WPF with new features. Me too, but unfortunately it's too late for that now. It's much too late to do what should've been done. The correct plan (new features in WPF) is no longer feasible.

Thus, I hate to say it, but now unfortunately the least-bad strategy is to continue WinUI 3 development, and keep WPF in maintenance-only mode. Sad but true.

However, my advice is that people should learn from their past mistakes, and stop banging their own heads against unbreakable brick walls. This means:

WinUI needs to be upgraded to managed code with a basis on .NETFW 5!

To be successful, WinUI needs to be firmly based on .NET Framework 5.0, like how WPF is based on .NET Framework. I know they call it ".NET 5.0" now, but I'll continue calling it ".NET Framework 5.0" anyway. WinUI needs to be upgraded to managed code with a firm basis on .NET Framework 5.

People need to stop making self-contradictory statements such as "upgrade to native code".
When people say "upgrade to native", fundamentally it ends up being equivalent to saying:

"We're going to waste our excellent staff members; we're going to squander their efforts by insisting on continuing a nonsensical self-contradictory plan that already failed catastrophically and caused tens millions of dollars of loss. We're going to insist on making our excellent team members work slowly in an impossibly-difficult and slow manner, because we prefer to slowly suffer for the next 20 years rather than suffer for the short-n-sharp 3 days it takes to acknowledge-and-change our past mistakes."

To be successful, it's necessary for the team members to stop saying things that they already know in their hearts to be false justifications, such as saying things along the lines of:

"We have to use native code because if we use managed code, the xbox teams will never accept it."

You guys already know that this xbox justification is a false justification. You know it already in your hearts. You've known it for a long time. So stop saying things that you already know to be false. I don't need to explain why the xbox justification is nonsense because you already know it's nonsense.
So how about starting to align your development plans and efforts with the various facts that you already know to be true and false?

Clearly Microsoft should never have started UWP/WinRT and WinUI. Clearly Microsoft should've continued development of WPF and .NET Framework. Unfortunately now it's too late to switch to the correct plan. Therefore, the next-best solution is to upgrade WinUI to managed code and a firm basis on .NET Framework 5.

Symbai commented 3 years ago

It's much too late to do what should've been done.

Ugh.. no?!?!?

This topic is about WPF and WPF only. Most of us don't care about WinUI, WinRT, UWP, Winforms, MAUI, Xamarin. Thanks for mentioning those again but, we still don't care. And we don't expect nor complain about lack of cross platform compatibility. If you care about native code or cross platform, go with Xamarin, MAUI, UWP or whatever. Developers choosing WPF to develop a GUI Windows desktop application with the advantage of XAML. If you want something else than WPF is not the right place for you, stop complain.

Ladies and gentlemen, all we complain about is an INACTIVE WPF team. All we want is more activity AND working together with the community. There is never a "too late to fix". All it needs is a team which is WILLING. WPF needs to get out of its "maintain" mode.

I for myself reduced my expectation even further by not expected some superb new features that costs 2,000 hours human power. But I expect that a one liner pull request gets reviewed within 2 weeks. Most of the pull request are so small and don't get reviewed that it freaks me out. Its such disrespectful for an open source community that it makes me speechless. And I expect that changes happening on Winforms also happens on WPF. I'm talking about Folder Browser dialog and Task Dialog. You can actually copy the work from Winforms.

That said, whoever leads WPF development has the wrong job and absolutely no passion. I'm sorry to say but that's obviously the truth. What it needs is a team like Winforms doing their job for their repository working together with the community, improving an existing and loved UI framework step by step.

verelpode commented 3 years ago

Another false justification for ceasing WPF was along the lines of:

"Breaking changes. We couldn't develop the new touchscreen GUI stuff in WPF because we needed to make MAJOR changes and such big API changes would've broken compatibility with all preexisting WPF apps."

What does the above really mean? What's the real underlying message? I'll translate it. Here's the translation of the above:

"I can't accept developing the new touchscreen GUI stuff in WPF and .NET Framework because the perfectionist in me needs to have its emotional needs satisfied. I view WPF and .NET Framework as dirty. I can't bring myself to touch dirty things. I need to start again from scratch in order to satify my urge for cleaniness. Oh but I know in my heart that this is wrong, so I can't speak this reason aloud, so I'll say the reason is 'breaking changes'."

The "breaking changes" justification is false because, for example, did apps break when Linq made drastic major changes to XML reading and writing? The Linq way of doing XML is very different and very incompatible with the prior XML classes. Did this cause apps to break? No, ofcourse not. Nothing broke.

System.Xml.Linq.XDocument was introduced and NOTHING BROKE, despite such big API changes. Ofcourse the reason why zero apps broke is because the prior classes (System.Xml.XmlWriter etc) continued to exist in .NET Framework, alongside the new Linq XML classes.

Linq and many other examples are proof of the fact that major API changes can be introduced, and already have been introduced many times, without breaking any apps.

Thus WPF development could've been continued, and new stuff for mobile devices could've been introduced in WPF and .NET Framework, without breaking any prior apps. Saying "breaking changes" as a justification is the emotional reasoning used when any perfectionist emotionally seeks to find an excuse to throw everything in the trashcan and start again from scratch, in an attempt to obtain the impossible goal of perfection and code cleanliness.

How do I know this so well? Yeah you guessed it. I understand this so well because I have the same problems as the people that I'm complaining about. I'm guilty of the same mistakes as them. But hey, we all make these mistakes. We're all guilty of it, but that's unimportant. Just fix it. It's admirable and impressive to fix mistakes.

verelpode commented 3 years ago

@Symbai wrote:

WPF needs to get out of its "maintain" mode.

I agree with you and I wish for the same thing as you. Unfortunately I have to be realistic about it, thus I'm forced to reluctantly acknowledge that there is zero chance of Microsoft deciding to begin development of new features in WPF.

wjk commented 3 years ago

To everyone in this thread and repository:

I have spent considerable time and energy creating a fork of WPF that can be used independently of the .NET runtime (it's just another NuGet package). I am more than willing to receive your issues and (hopefully!) PRs there. While I am committed to supporting this fork and WPF in the long run, I cannot guarantee any SLA on responses. I have a life like everyone else.

I have already merged most outstanding bug-fix and feature-request PRs from this repository into my fork. Three of the new-feature PRs will be treated as third-party contributions, so I can test the CI system. After that, I will cut a 1.0 release. Have at it, guys!

lindexi commented 3 years ago

@wjk Thank you. Can I merge my https://github.com/dotnet-campus/wpf/ to your repo?

I support your behavior. But I think it's too hard.

lindexi commented 3 years ago

@Thaval -- I agree. It is very frustrating. Unfortunately it represents management mistakes. It's a well-known classic management mistake to "throw the baby out with the bathwater" and start again from scratch. This strategy only occasionally succeeds. Usually this strategy results in failure, and failure is precisely what happened with WinUI formerly part of UWP formerly WinRT formerly Windows Phone 8. Catastrophic failure. Unfortunately UWP was a disaster of mismanagement that caused tens of millions of dollars of loss for Microsoft.

I agree with you. But I don't have any good ideas.

ClosetBugSlayer commented 3 years ago

When UWP used all-new namespaces instead of the System.Windows.* namespaces that defined WPF, that was a huge break with traditional Microsoft developer sensibilities. Even though the Win32 API could have hardly been considered similar between Windows 95 and Windows NT 4.0 and then Windows CE, they still kept the same function names AND parameters, and referenced the same header files.

If they hadn't messed with the namespaces, they could have sold it as a futuristic Silverlight. But the namespaces was the tell. Something is not right with this story.

Here's another thing: you don't have the source code to UWP when something goes wrong. You have it for MFC, WinForms, and WPF, but not UWP. They return you an HRESULT instead of a deep stack trace. It is not a friendly environment to be doing something as complex and volatile as UI, especially when there are zero books describing the internals as we had in the past. The only way forward is to absolutely sanction UWP and be willing to take independent action on WPF.

pjmlp commented 3 years ago

@verelpode Killing C++/CX (which is the only thing that ever came close to C++ Builder on MS stack), while at the same time keeping C++/CLI stagnant also didn't got much love from those of us in .NET land that are forced to occasionally write C++ code, because some Windows teams refuse to touch any kind of managed code.

Not only that, using C++/WinRT feels like we are back in the Visual C++ 6.0 with ATL days, even MFC is more productive.

wjk commented 3 years ago

@wjk Thank you. Can I merge my https://github.com/dotnet-campus/wpf/ to your repo?

I support your behavior. But I think it's too hard.

@lindexi Judging from the branch names, I've already merged some of your changes. For the rest, could you please send me PRs written in English (this includes the commit messages)? You can very much make a PR from one fork to another fork in the network. Don't worry if the PRs are full of unrelated changes and/or cannot merge cleanly; I can take care of that. I ask that you please enable the checkbox that lets me push to your PR, as it is a complex process and is difficult to accurately explain. Thanks so much!

predavid commented 3 years ago

Thank you for continuing to be active proponents of the WPF platform. The WPF team has been challenged with extremely limited dev resourcing for several months. With the highly limited resources on hand, we have been heads-down on getting support for .NET5 released and now are working on ARM64 support. However, the good news is that our team has now been approved for more new developer recruits to be on-boarded by the end of Jan/beginning of Feb 2021. We then expect to get going on more regular PR approvals and check-ins and Issue resolution. Please stay tuned for an update to our roadmap by the end of Jan2021. In the meantime, please continue to send us your PRs and file Issues -all of which only aid in improving the platform for the community . We look forward to closer and active collaboration with you in the New Year.

GeraudFabien commented 3 years ago

EFCore team used to be a really small team and have the same problem. And the fact they grow for EF5 was a big improvement (in my point of view). I hope it continue.

i don't ask for more support i ask to know what's going on.

if you can it would be interesting to know how many you are and how much you will be please ?

predavid commented 3 years ago

@GeraudFabien , at the moment we have just two developers on this project. We hope to grow to by another 3-4 developers in the next few months which will enable us to significantly expand the scope of work that we are able to undertake.

In the meantime, we have started merging more community PRs since mid-Dec : https://github.com/dotnet/wpf/issues/4052 These contributions came from @lindexi, @Nirmal4G, @thomasclaudiushuber, @TysonMN, @Youssef1313, @GrabYourPitchforks, @ForNeVeR, and @kant2002. A Big Thank you!

Please keep your contributions coming. We remain committed to active collaborations with the community in the months ahead.

GeraudFabien commented 3 years ago

Thanks

P0oOOOo0YA commented 3 years ago

OK am new to DOTNET and wanna develop a desktop app. What is your recommendation? Should I invest in WPF or WinUI?

thomasclaudiushuber commented 3 years ago

@P0oOOOo0YA Both are good options. The question is what you mean with "invest". Is this the investment of your time to build up knowledge, or is it an investment to build a huge app where you don't want to migrate in the future?

Regarding knowledge: WPF and WinUI are quite similar. Both use XAML, both have similar layout panels, both have similar controls etc. So, a WPF dev gets up to speed with WinUI quite quickly, and also the other way around. This means from a knowledge point of view, it doesn't matter too much if you start with WPF or with WinUI.

Regarding app investment: Both are great choices. WinUI 3.0 has now - like WPF already since years - a go live license for prod apps. So, if WinUI contains everything you need, you could start with WinUI 3.0. If you miss something, you could start with WPF. You can modernize your WPF later also with WinUI controls.

Has WinUI 3.0 everything you need? Go to the Microsoft Store and install the "WinUI 3 Controls Gallery" app to browse through the WinUI controls that you can use in your app (beyond this you can also use 3rd party controls)

But in my opinion, WPF and WinUI are both great options.

(Note that this month Pluralsight is free, I have a course called Fundamentals of Building .NET Desktop Applications that you can watch there for free. You will get an overview of WinUI, UWP, WPF, WinForms, MAUI, Uno, Xamarin, and you will learn how to build a desktop application for Windows with WinUI 3.0, WPF, and also with WinForms.)

GeraudFabien commented 3 years ago

@P0oOOOo0YA WPF has no new feature for (at least) 4 years, Has a lot of blocking bug. Only work on Windows. Lack a lot of really important feature... Whatever you choose don't choose WPF it doesn't work with .Net core or .Net 5 (Too much bug) and is clearly not supported for years whatever it's official status is. If you want proof just look at the commit of this repository...

I'm not sure i would use WinUI since it's also Windows only but if you really know for sure you will only use windows go for it. You should use Maui, UNO, Blazor if you want to use .Net. Or Flutter and React Native otherwise.

In .Net there is no real solution that work for now.

thomasclaudiushuber commented 3 years ago

Interesting @GeraudFabien, my experience is totally different about WPF on .NET Core/.NET 5.0, I have no problems. I migrated several bigger applications to .NET Core 3.1 and .NET 5.0. No problems. Lack of ClickOnce was the biggest issue. x:Name and also UserControls work for me.

@P0oOOOo0YA Here my view (also described in the linked video in my post above):

Windows apps:

Cross-platform:

From these cross-platform choices, Uno is the only one that is ready today. The others come with .NET 6.0. And as Uno is a WinUI bridge, WinUI is not a bad choice. WPF is also a great choice.

TysonMN commented 3 years ago

Thanks @GeraudFabien and @thomasclaudiushuber for those detailed descriptions. I have always found this ecosystem confusing.

[WPF] doesn't work with .Net core or .Net 5 (Too much bug) and is clearly not supported for years whatever it's official status is. If you want proof just look at the commit of this repository... [...]

  • WPF : Bug a lot in .Net core to the point it's hard to use (I can't even use X:Name or custom UserControl). A lot of nuget doesn't work with the core version...

Interesting @GeraudFabien, my experience is totally different about WPF on .NET Core/.NET 5.0, I have no problems. I migrated several bigger applications to .NET Core 3.1 and .NET 5.0. No problems. Lack of ClickOnce was the biggest issue. x:Name and also UserControls work for me.

My experience is more in line with @thomasclaudiushuber's than @GeraudFabien's. Instead of making broad claims about WPF being too buggy to use when targeting .NET Core 3.1 or .NET 5, I find it helpful to be specific.

I am the tech lead on a team that is creating a large WPF application targeting .NET 5.0. I am happy with our choice to use WPF for this project.

In my experience, the biggest issue with WPF when targeting .NET Core 3.1 or .NET 5.0 is this design-time bug when binding to DataContext. I workaround it by targeting .NET Framework for DEBUG configuration and .NET Core 3.1 or .NET 5.0 for RELEASE configuration. There is also a fixed released that I am excited to test.

I encountered bug #2956 that affects .NET Core 3.1 and .NET 5.0 but not .NET Framework. However, I provided a fix that was merged in PR #3493, so it should be gone soon.

Shortly after support for WPF when targeting .NET Core 3.1 was released, I was involved with https://github.com/elmish/Elmish.WPF/issues/154 that was about a weird binding issue. Unfortunately, I didn't spend the time to report this bug on WPF's GitHub. When I reconsidered the problem in https://github.com/elmish/Elmish.WPF/issues/197, the conclusion we came to in https://github.com/elmish/Elmish.WPF/pull/249#issuecomment-668777426 is that this bug had been fixed.

All other WPF bugs that I have experienced also exist when targeting .NET Framework.

GF-Huang commented 3 years ago
  • WPF: WPF is very stable and feature complete.

LOL, feature complete? TextBox no built-in placeholder/watermark supports you say feature complete? ListBox/DataGrid is very hard to scroll to the new item you say feature complete? Lacking too many necessary functions, WPF is like a car without wheels, even only an engine and chassis.

thomasclaudiushuber commented 3 years ago

@GF-Huang As I wrote, "Here my view". It's my personal view from building WPF apps in the last 15 years. Seems yours is different, that's ok. From my point of view, the framework is very stable and very feature complete. Yes, some Control functionality like placeholder is not built-in, but easy to manage with an attached property and adorners. It's a feature that could be there by default, but there are many easy ways to implement it, and there's even an example in the docs. Regarding scrolling I don't remember any issues with ScrollIntoView and UpdateLayout.

But anyway, I think the point of view depends on the size of application that you build.

  1. When you want to spend just one day to build an app with a few textboxes and they should have a watermark, then adding a watermark can be too much work, especially if you're new to WPF.
  2. When you build an application that takes more than 1 year of work, adding that watermark logic doesn't even matter. I did it in a few projects and never found that it's a feature that blocks me from anything. You can create an attached property or a base class.
  3. (more 2.1) Quite often enterprises use 3rd party controls, they have that stuff built-in. Should it be there in WPF too? Maybe the decision back then was actually to leave this to 3rd party controls. I don't know, but sounds reasonable.
GF-Huang commented 3 years ago

I know that, but why do I have to put wheels on the car every time before driving?

ClosetBugSlayer commented 3 years ago

I know that, but why do I have to put wheels on the car every time before driving?

Because maybe you don't know how to create software libraries yet. I fixed my deficiencies with WPF only one time and they stayed fixed.

I heard it once said that WPF makes hard things easy and easy things hard. On the one hand, you'll have trouble finding a WPF list control with lasso support. On the other hand, a single person who understands MVVM deep enough can write a massive multithreaded desktop application in record time with no help. That's why I'm not giving up on WPF... ever.

GF-Huang commented 3 years ago

I have to spend a lot of time each time dealing with some functions that seem to be readily available. Just like in reality you want to turn on the TV, but you find that a button is missing, you have to buy or make a button and install it in order to use the TV normally. Some features suck like placeholder/watermark, exist like air in other UI frameworks. You don't usually feel its existence, but you really need it.

GF-Huang commented 3 years ago

Regarding scrolling I don't remember any issues with ScrollIntoView and UpdateLayout.

And, ScrollIntoView not works when the DataGrid is grouping.

smourier commented 3 years ago

Have a look at Visual Studio 2022 roadmap https://docs.microsoft.com/en-us/visualstudio/productinfo/vs-roadmap#net

It says

Finally, we are working on a full designer experience for Windows Forms with .NET 5.

There's zero mention of WPF.

To me the path is clear (I'm talking Windows only, not cross-platform where the future is still blurry IMHO):

ygra commented 3 years ago

Finally, we are working on a full designer experience for Windows Forms with .NET 5.

There's zero mention of WPF.

Because the WPF designer already works, as far as I remember.

smourier commented 3 years ago

@ygra - Never said it didn't work as of today, I just said it's not in the roadmap, which means something.

ygra commented 3 years ago

which means something.

Yes, that the designer state is not as atrocious as with Windows Forms that it needs a dedicated team two years to make it work again. I do agree that WPF appears to be somewhat on life support (more so than Windows Forms these days), but that the Visual Studio roadmap only mentions the Windows Forms designer is not necessarily a sign I'd quote here.

thomasclaudiushuber commented 3 years ago

@smourier VS2022 is a WPF app, I guess that means something too. :-)

I don't understand why you think that WPF and WinForms should only be used with small and simple apps. The two UI frameworks work as good as in the past for big and complex applications, and as they were moved to .NET Core, you get all the improvements that come with .NET 5/6/7/8 etc. I don't see any reason why a dev shouldn't use WPF for the next big project. WinUI is of course the more modern approach that I would consider and check, but imo using WPF is a good decision too.

ClosetBugSlayer commented 3 years ago

There's zero mention of WPF.

I wouldn't start anything "big" with WPF and try to move anything "big" away from it.

Let me tell you something brother. WPF doesn't need a visual designer because you can do it cleaner and faster in Notepad just like websites in the 1990s. And it will continue to evolve because one of us is going to fork it if we can't get movement any other way. Let's just hope that special someone shares the changes they make or they will have one of the most hilarious creative monopolies of all time.

With WPF you have to go third party to see heaven. It's true, MS wasted billions on dumb internet businesses rather than buy up the best desktop control vendor for mere millions. MAUI is all closed-source hello world stuff for creating noob phone apps. Avalonia is merely the open source hello world stuff. Yet your LOB/creative app requires tight-looking menu bars and Visual Studio style docking controls on any thread they choose. Nobody is listening, you are being dictated to. The open-sourcing of WPF is the way out so let's make this project rock.

GeraudFabien commented 3 years ago

And it will continue to evolve because one of us is going to fork it if we can't get movement any other way.

Do it if you can. But it's nearly impossible. It's too complex to maintain alone.

MAUI is all closed-source hello world stuff for creating noob phone apps.

Why closed source. It's open source.

MS wasted billions on dumb internet businesses rather than buy up the best desktop control vendor

What are you talking about. ASP.Net didn't cost billions has far i know. Azure ?

Avalonia is merely the open source hello world

MAUI, Uno plateform, WinUI3 there is other solution than avalonia.

noseratio commented 3 years ago

Have a look at Visual Studio 2022 roadmap https://docs.microsoft.com/en-us/visualstudio/productinfo/vs-roadmap#net

It says

Finally, we are working on a full designer experience for Windows Forms with .NET 5.

There's zero mention of WPF.

To me the path is clear (I'm talking Windows only, not cross-platform where the future is still blurry IMHO):

  • WPF will never evolve (forever based on 20-years old DirectX9...). That doesn't mean it's "dead", it will continue to work as is for years hopefully.
  • WinUI 3 is the future of advanced / composited UI / XAML-like .NET apps. Note it's not fully ready yet, especially for non-packaged apps.
  • For more "simple" type of .NET apps, Winforms will still be there and still evolves somehow (hi-dpi scenarios, etc.)
  • I wouldn't start anything "big" with WPF and try to move anything "big" away from it.

@smourier, thanks for your thoughts, I've come to the same conclusion. I actually had ranted about it it before I found this thread, which I've now linked.

noseratio commented 2 years ago

There's a new sister thread, "The roadmap is outdated", worth linking here.

jonasnordlund commented 2 years ago

I think WPF is in an unfortunate situation with its reliance on an old DirectX version rather than e.g. Skia (which in turn uses Direct2D on Windows for rendering) and ties to Win32. It could have been such a great, pragmatic cross-platform framework with little to no need for MAUI. .NET Core was a gargantuan refactoring effort and it boggles my mind why Microsoft never put a similar, significant effort into WPF, only keeping it API compatible. They already have an estalished framework right here and it's great at windowing and UI.

I think it's a particularly unfortunate, sticky situation because while Windows App SDK 1.0 is now released (to surprisingly little fanfare), WinUI 3 is still not ready under WPF developer expectations. For example, you'll lose the XAML visual designer which was conversely even improved for WPF in Visual Studio 2022 (data mocking and MVVM support improvements) and WinUI 3 also lacks child window support. I bet many WPF apps want to open windows... These are to be tackled with Windows App SDK 1.1 later in 2022, but for actual platform maturity and time to see how the community accepts it, I think we're realistically looking into 2023 and beyond here.

And besides Windows App SDK, the only clear thing about UWP's future beyond WinUI 2.7 to me is that it's unclear.

So we're starting even new WPF projects today and felt reinforced by Visual Studio 2022 improvements for it, as well as Microsoft themselves demoing during .NET 6 with a WPF app despite the demo not being about WPF in particular. We also feel good about Microsoft.Toolkit.Mvvm. Right now I can only think of one big, lacking thing: Better Windows 11 API / UI support with the new controls and Mica material. In a perfect world, Microsoft would fork ModernWPF, update the control styles for Windows 11 styles, slap on a Window control attribute for Mica background and call it a day.

ClosetBugSlayer commented 2 years ago

WPF doesn't need innovation, it needs bug fixes and tuning. The hard work is already done. If anything, there needs to be more WPF applications to push the urgency of updating the platform. Nobody wants to waste time for hypotheticals.

UWP is dead on every level:

  1. The architecture is a closed-source abomination of spaghetti and an obstruction of all good things Win32.
  2. It offended WPF/Silverlight developers and created work for them, to the point where they left the ecosystem and became iOS developers. Combine this with the Windows 11 taskbar and you'd think Apple was running MS from the start.
  3. MS destroyed the mobile division it was intended for, opting instead to lose money with XBox rather than build on 1% of the trillion dollar mobile market.
  4. It has no business UI controls. LOB is not going to happen with UWP, ever.
  5. None of the UI controls in WinUI are properly respecting the airspace of the host frameworks.
  6. No killer apps. Terminal is not enough, I'd just as soon port it to WPF.

All of my work is in WPF and will always be in WPF. Step 1 of any contingency plan is to develop the missing business controls for Avalonia. MVVM keeps us independent of the UI framework and it really works.

pjmlp commented 2 years ago

@ClosetBugSlayer

Add to your list:

  1. No idea about 3D support, telling us to go learn C++ and DirectX isn't an option
  2. Picking on the previous one, even if we now C++, having to deal with C++/WinRT pre-historic tooling (ATL like) isn't modern, regardless how many times they use the term
  3. Messing around boilerplate code in project files and raw HWND calls to make use of Reunion APIs is a no-go
  4. If we need to rewrite the application (yet again, lost count since Windows 8), then we can just as easily go into another stack, cross-platform and free of the ongoing GUI-Framework war ongoing at Microsoft.
ClosetBugSlayer commented 2 years ago

In fact, UWP is such a bad Win32 citizen it would shock you all the Rube Goldberg infrastructure the OS has to carry to give it the illusion of seamlessness. It reminds me of our good friend the United States Federal Government. Windows Internals 7 Part 2 consumes a massive chunk of wood describing this waste of space. Thank you Mr. Ionescu for sacrificing your life-hours to such a heinous task.

You can't even run UWP exe's directly. My answer? Get outta here with that. Nobody ever asked for this weird inverted future. UWP has spies all over the OS whispering "if you're UWP don't eat the chicken soup" like Fight Club. Don't forget the zombie processes that are always adding cognitive burden to the power user (msedgewebview2.exe suddenly appears on screen like Agent Smith with his 4 friends for literally no reason at all, I guess it wants to question me, I better cooperate). On and on. It's disgusting, but anyone who loves tyranny would think it's awesome, maybe that's why the key on the cover of Part 2 is so evil looking compared to Part 1. It's like a dog snarling at you. The Key to Hell.

UWP windows thankfully have their own Win32 extended style bit that I can use to exclude them from all my parties: 0x8000. I might have to change my license plate to 0X8000 in gratitude to whomever did that. But I think MS itself needs this bit to quarantine the madness, otherwise they'd be digging two graves and not just ours. I hate UWP so much, if I see that bit I don't even include the window in my task switcher. You should see the notifications come in from RegisterShellHookWindow() for these UWP apps, they're completely rude and hilarious because of the contant HWND reparenting. I'm here! No, I'm there! Like an apparition in a hall of mirrors. UWP apps are generally single-instance so I can afford to let them be forgotten like the old Windows 95 file property windows. If you need them you know where they're at but you don't dare want them in your face pretending to be normal like the other apps.

All of UWP breaks the "social developer contract" of Windows desktop computing, the one Microsoft signed onto when it took 90%+ marketshare. I don't really have to say any of this, people just know it, and they express it by not developing new apps for it. When a framework is so lame, you don't even complain, you just walk away and say Who Cares and laugh. Next. Everybody just ghosts UWP, rofl. It was born in hate, let it die in hate. You should have been there in 2011 when they started telling us everything was going to be HTML/JS and that WPF/Silverlight would be discarded like caca; the dev atmosphere was really depressing. That has to be paid for and now's the best time to pay by ending UWP altogether. The funniest thing I ever saw was when Telerik open-sourced and discontinued all their UWP controls very early on, what a show of confidence.

You can't get rid of Win32, ever. Remember in the late 1990s when all the Linux users were saying that their OS was better because the POSIX APIs were stable for decades? Well, Win32 now has that elder status of computing and it's a thousand times more powerful than POSIX or UWP. WPF completely fulfills the promise of Win32. It just needs bug fixes and tuning. It will get them.

noseratio commented 2 years ago

Folks if you'd like you concerns to be heard, book a call with Microsoft, the .NET UI team is asking for feedback. Otherwise, this thread has been closed, venting here probably won't change much.

GeraudFabien commented 2 years ago

Otherwise, this thread has been closed, venting here probably won't change much.

I can re-open it if you want. But i believe it's better close. WPF is dead to me at least. Use blazor it's cross plateform and work better. I'm just sad Blazorize is not free for enterprise. Use uno or angular or react depending on you're need.

noseratio commented 2 years ago

I can re-open it if you want. But i believe it's better close. WPF is dead to me at least.

I think WPF will be kept alive as long as Visual Studio 20xx depends on it. Presently, VS 2022 is still built with .NET Framework 4.8.x.

GeraudFabien commented 2 years ago

Wpf and webform are bind to. Net framework support so ms can't drop support event if they want to.. Net supports is bind to the last version of windows shipping it. From what I understand. It was not my point. My point is wpf is old heavy to use lack a lot of feature isn't cross plate-form and buggy. Like web form it is still supported by Ms but it doesn't mean you should use it. The only good thinks about wpf is devexpress

AlexChuev commented 2 years ago

The only good thinks about wpf is devexpress

As DevExpress WPF developers, we are both humbled and feel bad for our favorite platform :) We love WPF and think that there are many good things about it:

Having worked with many WPF developers over the years, we consider WPF a stable and reliable platform with very few bugs. While it does not get too many new features, some important enhancements were implemented recently:

At DevExpress, we plan to continue our investment into WPF. Earlier this month, we shipped a version with 30 enhancements - new controls, features, MVVM APIs, XAML designer extensions, and significant performance optimizations. It will take us a few months to prepare a 2022 Roadmap, but I expect a significant part of it to be devoted to WPF.

KMastalerz commented 2 years ago

WPF never dies.

Yes there are multiplatform solutions, but WPF has so many open source packages that we can build reliable apps in matter of weeks.

For many business applications cross platform isn't actually needed when you build an app for accounting team. Also quite often you wouldn't want to buil a web app when companys boundwith is so stacked that nothing is loading fast.

for example:

If you build store go with web application

If you build any app that could be used by plenty of people go with cross platform solutions + web app.

For business solutions, where most companies use windows im going with WPF. Easy, fast and reliable. But only with MVVM.

Damn there are still thing build in console, so why hate so much on WPF. Its good, but not for everything, like most things in life :)

Thats my opinion. :)