71–80 of 102 posts
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.
So MS changed their mind not porting UI libraries to Net Core?
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?
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".
Earlier quoted context omitted.
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 cod…
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.
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...
They have a directive to move it to .net core - assume I assume this will make it cross-platform?
.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.
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…
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.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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 cod…
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…
Earlier quoted context omitted.
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 annoyi…
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.
Earlier quoted context omitted.
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.
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.