Make WPF cross-platform (MacOS and Linux support)

[x2bool]

Please port WPF to other platforms so we could use it to build desktop software for other operation systems.

[juanfranblanco]

Have you seen https://github.com/AvaloniaUI/Avalonia ?

[dotMorten]

It's definitely not in the current plan: https://github.com/dotnet/wpf/blob/master/Documentation/contributing.md

We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF.

Considering how platform specific WPF is, this would be a major undertaking

[alexbakker]

I'm not too familiar with how WPF works, but as far as I know it relies on D3D for rendering. In the case of Linux, someone would have to (a) port it to use GL(ES)/Vulkan and (b) write an X11/Wayland backend for it.

[kekekeks]

@alexbakker
I think that could be solved by linking to Winelib, but that's more of a packaging work that has to be done on application level rather than in WPF code

[feliwir]

Exchanging the current rendering backend with something crossplatform e.g. like https://github.com/mellinoe/Veldrid would be the correct approach in my opinion. Not sure why they explicitly state that they do not want something like that.

[richlander]

Just like @dotMorten says, we are not taking cross-platform implementations, per our Contributor Guide.

We look forward to many contributions to WPF. This request is out of scope for the project.

From a technical standpoint, WPF depends on multiple Windows components: D3D (DirectX), DWrite, User32, GDI+, WISP (Touch), and several others (including Windows Runtime dependencies). The interaction with these components is complex, critical and not architected with cross-platform in mind. As a result, our focus is on completing open source of WPF and bringing it to parity with .NET Framework.

I am closing this issue as a result.

[zezba9000]

As 'feliwir' says the rendering backend could be replaced or be updated and Windows specific APIs like GDI+ or other User32 APIs are already supported by Mono. Areas that directly link to WinAPIs via DllImports or whatever would just have to be ported to use the Mono version to start with (later ported to use .NET Standard). Just my thoughts without actually looking.

Maybe there should just be a WPF subset for other platforms like WASM, Android, iOS, etc.
WPF could be made to run as a UWP app as well.

[Kryptos-FR]

Disclaimer: what follows is a rant.

@richlander closing the issue and refusing the debate is a very dick move.

Now that WPF is open source and under the .Net Foundation, it is not up to Microsoft only what the future of it should be. If the majority of the community wants it, we have to at least try.

Seems like Microsoft still has a lot to learn how open source and communities work. I understand the difficulties and implications and possibly it will not be realistic to do so. But saying "no never" and "we will reject any attempt" is not a sane way to interact with the community. You have people ready to contribute for free to the project so you need to show at least some respect for their wishes and be more open minded.

[dotMorten]

@Kryptos-FR That's not really fair. He clearly stated it's out of the scope of what they can support, and it was already documented before this issue was logged, so what's there to debate? He never said you can't go ahead and fork this repo and attempt taking things cross-plat.
And we're not talking about a small part to flip a few switches to compile it against Linux and Mac - WPF is so closely tied to the Windows APIs, it is basically a complete rewrite, and code and UI was never designed for x-plat in the first place. IMHO I'd rather they focus on using their resources on improving WPF on Windows, than go on a wild goose-chase shoehorning this onto a Mac, and instead provide something more modern built from scratch that could be such a cross-platform UI, designed for xplat from the ground up.

[richlander]

Exactly, @dotMorten. We are being clear and transparent. In fact, I think we know exactly how open source works. We are setting the rules of engagement for this particular repo, but also licensed the code very favorably and are happy to see others use this code for scenarios that are out of scope for this repo. We're also happy to take code back, should it continue to be licensed favorably and it aligns with future scenarios.

We've also learned from our experience from CoreCLR, CoreFX and other repos. We have cases where issues have stayed open for years where nothing has happened. To a degree, we've voted by not applying any effort on some of those requests. That model is potentially more friendly, but it arrives at the same product outcome. That's not a bad model, but we want to avoid it where we have a clear point of view up front. That's what's happening here. It also allows others to stake their claim if they are passionate, with a clear sense of the engagement model with upstream.

Let's also be crystal clear. This is a very hard project. If the cost was low, this would be a very different conversation and very likely a different outcome. We have enough trouble being compatible with OpenSSL and that's just one library.

[zezba9000]

@Kryptos-FR MS is just taking the position (from my perspective) of they're not going to spend money supporting platforms they don't 'directly' make money in or is hard for them to measure the value of short term (which is a little off as they supports macOS but only for the sake it brings in Azure developers not realizing I think people need better client side tools to even use Azure [thats a larger topic though]). Thus Its the communities responsibility to fork and port WPF and if it does have value to MS (which I would argue does) the community will have to illustrate that to MS. This is just how big companies work which sometimes don't see the value of innovation outside their bubbles / eco systems if you will.

There is a lot of value in a cross platform XAML that looks the same on every platform, is compile type checked, has a visual editor in an IDE and based around the .NET or C# eco system. MS has at least given people a starting point if they have the resources to port it (which is far more than I expected to happen tbh).

@dotMorten Many apps written in WPF would have great value on other platforms. If these apps were using Azure it would end up making MS money in the long run. People who don't see this value are a little disconnected I think. .NET Core has solved the cross platform issues in its eco system in every aspect besides the desktop and client side (no HTML is not the answer for many reasons). It is in some ways both MS's and the communities responsibility to solve that remaining client side UI issue as both parties will share the rewards. In this case I think the community has to start the trail rolling.