
Windows Presentation Foundation (WPF) on GitHub - pjmlp
https://github.com/dotnet/wpf
======
phdsolutions
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](https://www.tagthatphoto.com)

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

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

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

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

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

~~~
maxxxxx
That's a big issue but it doesn't explain why instead of developing WPF they
released WinRT and UWP.

~~~
contextfree
The purpose of WinRT was to avoid having to depend on .NET. Developing WPF to
fix this would have meant rewriting the whole thing in C++, which is what
Silverlight/WinUI sort of was, but I agree they dropped the ball on
compatibility and migration

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

~~~
alkonaut
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_fayer
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.

~~~
maxxxxx
They could easily have done this but instead chose to make several new
frameworks that didn’t improve anything. Very sad. Now MS has several mediocre
not well maintained frameworks instead of a really good one. The constant
churn also killed off a lot of open source efforts

~~~
DoofusOfDeath
This isn't my area of expertise. What are some of the other MS frameworks or
OSS projects you refer to?

~~~
maxxxxx
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 code.

When WPF came out there were quite a few very cool open source projects that
built on top of it because it's really easy to extend WPF and build components
for it. But then every two or three years MS announced a new framework so most
of these efforts died out. When you look at commercial third party suppliers
like Developer Express they have the same component in three or four flavors.
this must be a huge and expensive effort to maintain.

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

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

~~~
alkonaut
Yes. But for one of these to really take off, I think what's needed is for one
of the giants to throw their weights behind it. Basically "We're betting x
billions on it, so you can be sure that lots of companies will be using this
tech in the decade to come".

------
Kuraj
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
.Net Core is cross platform. So, WPF is cross plaftorm now as well

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

WPF relies on Windows specific functionality.

~~~
pjmlp
MFC used to be cross platform (Windows / Mac OS System 7) during the early
days.

------
cltsang
Reading this official Xamarin Forms document [https://docs.microsoft.com/en-
us/xamarin/cross-platform/desk...](https://docs.microsoft.com/en-
us/xamarin/cross-platform/desktop/controls/wpf) 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?

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

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

------
dinglejungle
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/720)

[https://github.com/dotnet/wpf/pull/727](https://github.com/dotnet/wpf/pull/727)

~~~
ygra
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](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.

------
iforgotpassword
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?

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

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

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

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

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

------
thebruce87m
What are the implications of this? WPF in Linux?

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

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

~~~
Crinus
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 other languages
and desktop tech? WPF alone wasn't exactly popular on Windows itself.

~~~
colde
Because once you understand it, WPF and C# is fantastic to work with. It's
hands down the best UI framework i have ever worked with.

XAML makes it very easy to layout apps that scale well, and it's built-in
states for controls and easy styling is very handy.

~~~
Crinus
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 considering the market share it already can cover
and that even among that market share isn't exactly popular, not how good WPF
is.

~~~
pjmlp
Ever bothered using Blend?

Former Delphi / C++ Builder fanboy here.

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

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

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

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

