51–60 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?
Kitbashing this with winelib will probably be the best way to do it.
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.
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).
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.
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…
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)
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.
Please elaborate?
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...
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…
You can add a design time view model to get compile time warnings(and autocomplete) about incorrect bindings.
Earlier quoted context omitted.
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 o…
So MS changed their mind not porting UI libraries to Net Core?
Earlier quoted context omitted.
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.
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.