Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Presentation Foundation (WPF) on GitHub

github.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Windows Presentation Foundation (WPF) on GitHub

#91

Post by wiso »

m_fayer wrote: post #78
alkonaut wrote: post #74

Earlier quoted context omitted.

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…

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

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.

Re: Windows Presentation Foundation (WPF) on GitHub

#92

Post by wiso »

m_fayer wrote: post #23
alimbada wrote: post #18

Earlier quoted context omitted.

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

Re: Windows Presentation Foundation (WPF) on GitHub

#93

Post by pjmlp »

m_fayer wrote: post #90
pjmlp wrote: post #85

Earlier quoted context omitted.

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 g…

"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.

Re: Windows Presentation Foundation (WPF) on GitHub

#94

Post by Crinus »

pjmlp wrote: post #88
Crinus wrote: post #48

Earlier quoted context omitted.

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 consider…

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).

Re: Windows Presentation Foundation (WPF) on GitHub

#95

Post by Crinus »

pjmlp wrote: post #87
Crinus wrote: post #22

Earlier quoted context omitted.

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 othe…

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.

Re: Windows Presentation Foundation (WPF) on GitHub

#96

Post by pjmlp »

Crinus wrote: post #94
pjmlp wrote: post #88

Earlier quoted context omitted.

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 t…

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.

Re: Windows Presentation Foundation (WPF) on GitHub

#97

Post by pjmlp »

Crinus wrote: post #95
pjmlp wrote: post #87

Earlier quoted context omitted.

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.

Re: Windows Presentation Foundation (WPF) on GitHub

#98

Post by wiso »

maxxxxx wrote: post #39
acct1771 wrote: post #37

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…

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

Re: Windows Presentation Foundation (WPF) on GitHub

#99

Post by pjmlp »

WorldMaker wrote: post #73
iforgotpassword wrote: post #67

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 i…

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.

Re: Windows Presentation Foundation (WPF) on GitHub

#100

Post by maxxxxx »

pjmlp wrote: post #85
maxxxxx wrote: post #64

Earlier quoted context omitted.

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.

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.

Post reply on HN