Hacker News Reader

Comment by mr_overalls | Hacker News Reader

I hated to see this advice to contributors:

"We will typically not accept contributions that implement support for an OS-specific technolology on another operating system. . . We also do not intend to accept contributions that provide cross-platform implementations for Windows Forms or WPF."

https://github.com/dotnet/wpf/blob/master/Documentation/cont...

Microsoft seems to be actually refusing to accept contributions that could make WPF cross-platform - it's a bit beyond "no official plans for cross platform".

View on HN

Neither Windows.Forms or WPF can easily be made portable, the code is really a thin layer on top of existing Windows services.

I know, because I did this before with Mono, and the changes would be highly disruptive to the codebase.

If someone wanted to attempt it, it would make much more sense as a fork rather than part of the mainline.

Well, he started the Mono Project :)

So he did. I feel as if I've arrived - I just got corrected by Miguel de Icaza. :-)

Which is probably the reason they open-sourced it... Not much difference anyway.

Except people can contribute to features/bugs for the platform that they do support?

Not to be overly cynical, but this is kind of obvious: that means your contributions really only benefit Microsoft in the long run. Sure you might derive benefit, but Microsoft is the real beneficiary here, and they don’t even have any obligation to pay you.

"Is the current situation better for the customer than the one yesterday?" is the way I like to think about these things.

Name an open source freemium project run by a for-profit company which /doesn't/ benefit the company more than the individual submitting patches?

Would it be relatively easy to shim to use Wine (where available)?

You could already use Mono with Wine

The dotnet installer still needs hacks, right?

Use Python QT, it is portable. No need to invest time and effort in non-portable GUIs.

And their whole .Net is full of patents.

PyQT can be considered a reasonable (and in many ways superior) alternative to WinForms but what about WPF? Is there a modern cross-platform non-browser declarative 2-way-binding MVVM desktop GUI toolkit? I use PyQT mysef but I really wish I could use binding instead of just handling events manually.

Why not just use Qt then?

Open source doesn't mean open development and liability & commitments. They are different things.

I actually think MS did a great job by saying that. The purpose is to literally make the source public but they don't have resources to make a long commitment. Then it's better to not say it clearly and later got accused as not well performing.

Partially true ..

> Open source doesn't mean open development and liability & commitments.

Right. We are stating up-front what we intend to achieve. We will sart with making WPF on .NET Core have parity with .NET Framework and then expand from there. We'll stick to Windows as the OS for the project.

> The purpose is to literally make the source public but they don't have resources to make a long commitment.

We are not saying that. We intend to continue working on WPF. In fact, we are talking about moving some of Microsoft's 1st-party apps to WPF on .NET Core, just like how we're moving 1st-party web sites/services to ASP.NET Core and .NET Core. Same playbook.

Right, by releasing the code they're saying "here's some nice code, do what you want with it", but not "oh and we're increasing our investment into this product by expanding the team" which is what adding non-Windows support to their official repository would entail.

Exactly. I think MS is a doing a gesture job to showcase their code, but they are not open sourcing the roadmap to the community, which is fine by me actually.

In that Git repository.

Nobody should be submitting pull requests for cross-platform support into WPF's main Windows repository. Instead they should branch WPF, make a platform specific version (e.g. WPF-Linux, WPF-MacOS, etc), and submit pull requests upstream that are platform agnostic (e.g. bug fixes).

That's not the approach they've taken for other cross-platform work. Doesn't sound very efficient either.

It's very efficient for Microsoft. Evaluating pull requests for a different OS requires entirely different QA. At the end of the day, it's open source. Fork it.

You cannot contrast a Windows specific piece of code like WPF with projects that were created with original cross-platform support like .Net Core, it is an apples and oranges comparison.

If they were starting WPF again today they might create an agnostic master, which has a Windows specific branch. But they aren't restarting WPF, they're just open sourcing what they already have.

The difference is that with .NET Core they are committed to providing support for the cross platform implementation. With WPF they don't want to provide any official support or the idea that they might, so they're leaving the implementation up to 3rd parties that would be responsible for keeping the whole system working with any upstream changes.

They don’t intend these to be cross platform, so what they do with cross platform work isn’t really the issue.

Suppose someone came up with .NET bindings for MacOS GUI controls, or Gnome. Would you expect a Microsoft to adopt those into .Net Core?

MicroSoft have two roles here. On the one hand they are the custodians of the cross platform .NET Core system. In the second role they are the Windows platform owner and provider of .NET bindings for some platform specific features.

If you decide to contribute to .NET Core, you join them in the first effort. If you come up with Gnome bindings or such, you are in the latter role but just because you are creating those bindings you’re under no obligation to port Gnome to Windows or anywhere else. Bindings for existing platform specific features are clearly in a separate category from shared cross platform features.

Easier to conveniently forget about some repos

At which point it's easier just to use Eto.

Supporting cross-platform WPF (or WinForms) at this point would be a terrible idea for Microsoft.

These frameworks have been around for many years, and many (if not most) of the applications built on those frameworks make heavy use of third-party control libraries. Those libraries, whether open source or propriety, often include at least some win32-specific interop code that has also been around for many years. Most of those libraries are now in “maintenance only” mode, if they’re even being maintained at all. Realistically, most Windows GUI applications built on .NET will never run on any platform other than Windows, even if the core UI frameworks become cross-platform.

As soon as Microsoft says, “WPF is cross-platform now”, they’d get flooded with bug reports that aren’t even related to their code.

Wow, someone who makes sense for once. I love and embrace open source but I'm sure as glue that the developers who want cross platform winforms and wpf will never use it.

I agree. My thinking is that the only place where any desktop app is still actively developed is the enterprise (and even there the trend is to get everything web based), and this is predominantly a windows environment. Outside of the enterprise everything has gone mobile where wpf isn't really an option (solutions like Xamarin aren't fun to use).

My guess is that desktop apps will come back with pwa+wasm. Then you can have a rich client that is fully cross platform, single code base, same behavior everywhere, easy to deploy, written in the language of your choice. But that doesn't involve wpf...

How are they supposed to evaluate such contributions? They would need to set it up in their CI, know details about those platforms, etc. What if the first contributor uses X11 apis and then somebody else wants to use Wayland, another wants to use (whatever hardware accelerated graphics API)... are they to reject everybody who wasn't first?

I would suggest that any initial support for cross platform efforts be centered around WINE myself. Likely the least friction. Not that I care.

Its not that much different than the Linux kernel in that respect. Eg, you cannot submit a driver w/ifdefs and compat shims for other OSes.

Theoretically you can still get WPF running on another OS, but you'd have to do it the same way that WSL gets an Ubuntu userland running on Linux: You introduce a compatibility layer that it runs on top of.

I think I'd prefer that approach, anyway - I'd guess it's cleaner and ultimately more maintainable than introducing a whole bunch of conditional logic for handling all the cross-platform issues into an already complicated piece of software.

WPF already has such a layer, actually - Media Integration Layer, MIL.

But this isn't a kernel - it's a framework with explicit goals of being cross-platform.

No, it never had a goal of being portable to non-Microsoft platforms, and it doesn't suddenly add that as a goal just because it's open source now.

Well for WPF there was silverlight for a while, a limited but (gimped)cross platform version of WPF.

I wouldn't be surprised if there were abstractions to make porting to openGL easier.

> it's a framework with explicit goals of being cross-platform

where did they notate their goals for wpf and winforms to be cross-platform? they specifically mentioned they open-sourced them to open up windows development.

You're right. I mistakenly conflated the goals of wpf with dotnetcore.

Open source doesn't mean they have to accept any old feature you want to add to their project.

Who's going to pay to buy the new CI machines they need to run someone's macOS backend that they contribute for example?

Be reasonable.

If they gave people the illusion that they could make WPF cross-platform it would mean a lot of wasted time for both Microsoft and the contributors. So it's probably better to remove that illusion right away.

People can always fork and work on it, Microsoft is just sending the message that they won't do any work to incorporate any of it. Open-sourcing something is not an obligation to keep maintaining something.

I don't even know what the appeal of WinForms/WPF is these days. They don't really offer UI controls or a user experience that's better than well-done websites or electron apps.

It's MIT licensed. Who cares about the rules on their repo when you can just fork it?

If you want to do that, then fork it. Microsoft isn't stopping you from doing that.

I guess that this very clear positioning from Microsoft means that there is still room for someone to come up with a XAML UI kit for .NET Core, and name it it CPF (Core Presentation Foundation) instead of WPF (Windows Presentation Foundation).

I understand that the open source WPF can be freely used as a reference from where to borrow a few things.

Can't you just fork the project and make your own cross platform WPF and Windows Forms? Name it something else and don't give the code to Microsoft?

What a pity. It would be cool to target canvas with winforms somehow, and just use that through wasm.

Fork it, what's the big deal? What would you do if someone rejects your PR anyway?

Thank you, Microsoft.

Keep it contained in Windows! WPF apps are shoddy.

Reply on news.ycombinator.com