Windows Presentation Foundation (WPF) on GitHub

https://github.com/dotnet/wpf

by pjmlp • 7 years ago

117 100 7 years ago

github.com

dinglejungle• 7 years ago

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

keithnz• 7 years ago

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

ygra2• 7 years ago

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.

thebruce87m• 7 years ago

What are the implications of this? WPF in Linux?

mariusmg• 7 years ago

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

nitrogen• 7 years ago

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

nathanaldensr• 7 years ago

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

ygra2• 7 years ago

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.

oaiey• 7 years ago

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

Kuraj• 7 years ago

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

gzimhelshani• 7 years ago

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

Crinus5• 7 years ago

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

WPF relies on Windows specific functionality.

ZanyProgrammer• 7 years ago

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

maxxxxx17• 7 years ago

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

alimbada• 7 years ago

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

m_fayer6• 7 years ago

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.

dazrafio• 7 years ago

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

WorldMaker2• 7 years ago

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.

Traubenfuchs• 7 years ago

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

thrower1232• 7 years ago

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.

alkonaut3• 7 years ago

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.

m_fayer6• 7 years ago

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.

JamesBarney4• 7 years ago

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.

joelfolksy• 7 years ago

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.

mgoetzke• 7 years ago

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.

maxxxxx17• 7 years ago

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

osd• 7 years ago

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.

glonq• 7 years ago

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.

phdsolutions2• 7 years ago

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

moron4hire• 7 years ago

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.

JamesBarney4• 7 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.

balabaster• 7 years ago

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.

OkGoDoIt• 7 years ago

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.

phdsolutions2• 7 years ago

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/

finchisko• 7 years ago

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

cheerlessbog• 7 years ago

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

maxxxxx17• 7 years ago

Yes, until they change their mind ;)

skc• 7 years ago

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.

klodolph• 7 years ago

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.

maxxxxx17• 7 years ago

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.

sdegutis• 7 years ago

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)

polygotdomain• 7 years ago

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.

cltsang• 7 years ago

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?

maxxxxx17• 7 years ago

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.

JamesBarney4• 7 years ago

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

polskibus2• 7 years ago

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

amyjess• 7 years ago

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.

polskibus2• 7 years ago

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

maxxxxx17• 7 years ago

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.

iforgotpassword• 7 years ago

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?

maxxxxx17• 7 years ago

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

WorldMaker2• 7 years ago

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

pjmlp10• 7 years ago

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.

Windows Presentation Foundation (WPF) on GitHub

Related Stories