Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make WPF cross-platform (MacOS and Linux support) #48

Closed
x2bool opened this issue Dec 4, 2018 · 103 comments

Comments

Projects
None yet
@x2bool
Copy link

commented Dec 4, 2018

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

@vatsan-madhavan vatsan-madhavan added this to the Future milestone Dec 4, 2018

@juanfranblanco

This comment has been minimized.

Copy link

commented Dec 4, 2018

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

@dotMorten

This comment has been minimized.

Copy link
Collaborator

commented Dec 4, 2018

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

This comment has been minimized.

Copy link

commented Dec 4, 2018

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

This comment has been minimized.

Copy link

commented Dec 4, 2018

@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

This comment has been minimized.

Copy link

commented Dec 4, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 4, 2018

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

This comment has been minimized.

Copy link

commented Dec 4, 2018

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

This comment has been minimized.

Copy link

commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2018

@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

This comment has been minimized.

Copy link
Member

commented Dec 5, 2018

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

This comment has been minimized.

Copy link

commented Dec 5, 2018

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

@dotMorten

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2018

@zezba9000 Don't get me wrong: I'm not at all saying a cross-platform UI is a bad idea and not needed - what I'm saying is I think making WPF cross-plat would be a waste of (a lot of) resources, and we'd be better off inventing something new from scratch - also IMHO if we were to go the XAML route, we'd be better off starting with UWP as a base.

@zezba9000

This comment has been minimized.

Copy link

commented Dec 5, 2018

@dotMorten I agree WinUI might be a better base or something new that lives outside of the platform its running on conceptually (then platform specific APIs like .NET Core has for Windows now could be made). This would also help MS from needing to keep reinventing XAML for each new platform they create. If WPF was designed correctly to start with, they could have just had a WPF version running as a UWP app. If that makes sense.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

@xiexin36

This comment has been minimized.

Copy link

commented Dec 5, 2018

Please at least be open to discuss these.

@10Dev

This comment has been minimized.

Copy link

commented Dec 5, 2018

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.

@richlander Perhaps you could reconsider and simply take the well worded contents of your post above to insert into this issue's "description" and then suffer the annoying situation of leaving the issue OPEN forever which you stated is a possible option.

Considering how well-loved WPF is to so many people, you might be faced with a multitude of endless repeats of this issue. By taking the current approach, it simply does not "read well" and comes off cold-hearted through no bad intent of yours, just the situation.

I'm just suggesting that it will calm everyone down and leave a "safety valve" if you just leave this open as a kind of "wisdom of the crowds" or just plain old wisdom...

@Ran-QUAN

This comment has been minimized.

Copy link

commented Dec 5, 2018

I think what the community want is just an open source, cross-platform XAML-based UI framework, not a cross-platform WPF. We can have an open source cross-platform XAML-based UI framework, because we now have WPF open sourced, we can take the stuff and build one, but the one we'll be building is just not WPF, it just won't exist in this repository under the name of Windows Presentation Foundation.

So I think the correct question should be 'Can we have an open source, cross-platform XAML-based desktop solution?'. Apparently it's not an easy one to answer.

@raffaeler

This comment has been minimized.

Copy link
Collaborator

commented Dec 5, 2018

@Ran-QUAN frankly speaking I am not sure that would be the right direction. Let me say that many years ago I asked several times to port WinRT/XAML cross-platform, but now many development shifted to web and mobile, and XAML failed to improve over the years.

Don't get me wrong, I love WPF and wrote tons of apps but there are multiple flaws in XAML.

  • The inability to provide a solid designer is a major stopper for most of the developers. I stopped using a designer a long time ago but it is still a blocker for many.
  • The verbosity of XAML was supposed not to be a problem because initially the designers would manage that. But in large apps, you have to take care of your XAML by hand.
  • XAML in UWP and WPF is significatively different. And in UWP there are a lot of missing features that prevented porting many apps. What XAML are we talking about? Is the WPF one (the most complete) really the best? I don't think so.
  • The missing lifecycle of the views (pages or simply windows) is a major problem for writing a decent MVVM support.
    Those are not the only things of course, just the first ones I had in my mind. Converters syntax and versatility can probably be easily fixed and improved but they have been a source of complains for years.

Paradoxically it's far more easier to port winforms cross-platforms (as Mono had for years using Wine) in comparison to the effort of WPF (because of DX and other components). Not the best choice at all, but definitely the fastest.

@costincaraivan

This comment has been minimized.

Copy link

commented Dec 5, 2018

@richlander In my opinion @10Dev is right, put part of your comment into the Contributing Guide and make that a bit softer. The soft approach could be something like this:

"We will accept contributions that make WPF cross platform provided that they come through high quality pull requests, which include:

  • a detailed architectural plan justifying the decisions made
  • detailed specifications of the changes made
  • good test coverage for the contributed code
  • widely adopted, stable and high quality dependencies."

This would kill basically all "hit-and-run" contributions I assume you're afraid of 😄

@danwalmsley

This comment has been minimized.

Copy link

commented Dec 5, 2018

Why not focus on existing projects already modelled from uwp and wpf like http://github.com/AvaloniaUI/Avalonia that make this already a reality, with many apps already using it.

@zezba9000

This comment has been minimized.

Copy link

commented Dec 5, 2018

@danwalmsley (Unless this has changed) The big issue with Avalonia is it doesn't generate C# types in a partial class for the code behind allowing for type safe / compile time checked XAML. Which both WPF and WinUI do. This is a huge advantage over HTML, Androids UI, QML etc. Without this Avalonia really isn't that different from using some other UI that relies off runtime errors instead of compile time ones.

Also companies like Telerik etc aren't supporting it like they're with WPF and WinUI. You say we should extend existing projects but why not extend the ones that already have much larger support and tools? I see nothing wrong with changing direction when new doors open is all I'm getting at.

@kekekeks

This comment has been minimized.

Copy link

commented Dec 5, 2018

DevExpress/Telerik products also rely on Win32 API or DirectX. We've tried to port some open-sourced Telerik controls from UWP to Avalonia and discovered that we can't because they are using custom DirectX rendering.

@worldbeater

This comment has been minimized.

Copy link

commented Dec 5, 2018

Glad to see .NET evolving! Hope Avalonia will also become a part of .NET Foundation someday. Really an impressive framework with poweful styling system. WPF, beloved by many developers, could borrow some ideas from that framework, like value conversion syntax, binding to async values or binding from code. Worth mentioning, that we can already create cross-platform applications using ReactiveUI or Caliburn.Micro frameworks alongside with Xamarin, WPF and Avalonia 🥇 💯

@HumanEquivalentUnit

This comment has been minimized.

Copy link

commented Dec 5, 2018

@Kryptos-FR

Seems like Microsoft still has a lot to learn how open source and communities work. [..] 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

Have we learned nothing from the recent Node/NPM disaster? Communities don't get to make demands on people who give their hard work away for free. Even if it's Micrsoft and even if you hate them.

See Rich Hickey (creator of Clojure)'s comment here: https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9

The only people entitled to say how open source 'ought' to work are people who run projects, and the scope of their entitlement extends only to their own projects.

Just because someone open sources something does not imply they owe the world a change in their status, focus and effort, e.g. from inventor to community manager.

As a user of something open source you are not thereby entitled to anything at all. You are not entitled to contribute. You are not entitled to features. You are not entitled to the attention of others. You are not entitled to having value attached to your complaints.

Asking for it, asking about it, is OK. Stating that someone needs to listen to you because you have demands and you want more free things, is not OK.

However the gravity to use existing knowledge and code bases is probably strong for WPF. Just look at the stars on WPF vs WinUI in GitHub... people clearly want a WPF like Desktop solution more than something else. From what I can tell. Its a lot faster to dev with for sure.

People are aware they can pay for Windows and get WPF .. right?

@juanfranblanco

This comment has been minimized.

Copy link

commented Dec 6, 2018

@worldbeater it looks that you are trying to achieve the same as me, mixing ReactiveUI + "xUIFramework" (Prism, MVVMCross, Caliburn.Micro) to create a generic set of guidelines / framework for cross platform applications (https://github.com/Nethereum/Nethereum.UI.Desktop). Your example is excellent (https://github.com/worldbeater/ReactiveMvvm).

Now although slightly off topic if we could have alignment on frameworks too (Prism, Cross, Caliburn, MvvmLight) that could support all platforms, for scenarios simple and complex (depending on the platform) for navigation, menus, good old regions, module injection, etc that will be awesome, so much knowledge, work and many lessons learnt we had with WPF, Silverlight, Xamarin, Avalonia, etc, etc and all the frameworks that have been created to support them.

@glyad

This comment has been minimized.

Copy link

commented Dec 6, 2018

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

I just want to explain, why I can't like your proposal with Avalonia.

  1. Your advertisement is off topic, since we are discussing WPF here.
  2. The AvaloniaUI is pretty nice project, great work, but...
  3. AvaloniaUI lacks compatablity with WPF framework;
  4. it's simply impossible to compile WPF-based sources (excluding platform dependend code) with Avalonia
  5. it hasn't support from UI control vendors;
  6. etc...

Let's think together, how to reanimate really great framework, which serves thousands of serious projects perfectly, and do not vaste community resources with to develop another Xamarin, or Silverlight, or UWP, or something another.

@ebugusey

This comment has been minimized.

Copy link

commented Dec 6, 2018

It's an open source project. You can fork it and do with it whatever you want.
If dev team doesn't want to support some other platform it's in their right to do so. Because being cross-platform is not easy, especially for UI components.

@DaZiYuan

This comment has been minimized.

Copy link

commented May 29, 2019

I think you guys need google flutter. I really hope xaml can be a cross platform UI toolkit,but it seems impossible forever

@Atulin

This comment has been minimized.

Copy link

commented Jun 27, 2019

I think you guys need google flutter. I really hope xaml can be a cross platform UI toolkit,but it seems impossible forever

Flutter does not export to desktop targets yet, unless you jump through a few hoops to use stuff that hasn't even been added to the tooling yet.

I guess with Microsoft ignoring cross-platform UI frameworks and Avalonia having close to no documentation, I'll have to either learn Java or resort to the dreaded Electron...

I love C# and .NET and want to use it everywhere, but I guess Microsoft doesn't want me to. Did they invest in Electron stocks or something and are deliberately pushing people in that direction?

@DaZiYuan

This comment has been minimized.

Copy link

commented Jun 27, 2019

Sorry for my negative comments before.

I really wish there is a UI framework just like Flutter,
It allow me use c# develop high performance application in any platform(ios/android/web/desktop/other platform).
xaml + visualstudio + a set of API ( no more different API,such as xamarin/uwp/wpf/wp8/wp8.1/silverlight).

Developer can use one .Net tech develop app to any platform . this will be beneficial to .Net open source community and Microsoft app store also will get more apps

@lindexi

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

@DaZiYuan Try Xarmain

@DaZiYuan

This comment has been minimized.

Copy link

commented Jun 27, 2019

I tried before ,it seems map control to native platform, can not keep same UI in different platform.
and don't like it. if I had to choose I would choose flutter. Flutter has a bigger community.

@x2bool

This comment has been minimized.

Copy link
Author

commented Jun 27, 2019

@DaZiYuan Try Avalonia. It is very similar to WPF.

@Ruedii

This comment has been minimized.

Copy link

commented Jul 3, 2019

There is the option of creating a lightweight partial WPF framework. The elements implemented in WinPR or Winelib (Not full Wine, obviously) could be used for most functions. This would cover the vast majority of end usage of WPF. Thus leaving the only portion not supported to be Driver Framework, Kernel Framework, System-Wide Font Management, any Bare Metal functions and Windows Services Framework. Many of these would be possible to a large degree with a full Wine environment but obviously we don't want to implement a full Wine environment just to run WPF applications, and anything that uses those utilities will be platform specific.

A stripped WPF containing GDI+, MSXML, MSHTML, MSHTTP, WinSocks, Print Spool access, DirectX, TWANE and a good number of other Win32/WIn64 libraries already implemented by portable Open Source projects should be fine.

@glyad

This comment has been minimized.

Copy link

commented Jul 3, 2019

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

Please stop to advertize your project here. Yes, Avalonia is very promissing attempt, but it isn't an open-source implementation of WPF framework. It isn't WPF at all, since it isn't compatible with WPF at least in meaning that I cannot compile an existing WPF project with Avalonia. Let's talk about WPF here!

@glyad

This comment has been minimized.

Copy link

commented Jul 3, 2019

@DaZiYuan Try Avalonia. It is very similar to WPF.

The word "similar" doesn't mean "equals". Can you run on Avalonia a project, which has 5-7 years of the development livecycle. No? How you can help me with your Avalonia?

Can you try do not advertize Avalonia project in the thread of WPF project? ;)

@glyad

This comment has been minimized.

Copy link

commented Jul 3, 2019

IMHO, that's possible to create cross-platform implementation of WPF. All you need is following:

  1. Make public WPF API as 100% compatible to current WPF implementation,
  2. Separate WPF from rendering engine and make it possible to develop rendering backends (e.g., DirectX, OpenGL, WebAssembly, etc.),
  3. Separate interface from platform-dependent implementations (e.g., implementation of the browser control, common OS dialogs, etc.).

That's all... or..?

@zezba9000

This comment has been minimized.

Copy link

commented Jul 3, 2019

@glyad A 100% WPF implementation would require something like WINE. Thats not practical. Making a WPF subset might be possible that removes Windows specifics.

Also look up WinUI 3.0. If anything that should be ported later as its the WPF replacement for desktop (fingers crossed its done in a way porting is possible).

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@MrJul

This comment has been minimized.

Copy link

commented Jul 3, 2019

I'm surprised nobody mentioned NoesisGUI yet (or if they did, I missed it).

It's a really performant cross-platform implementation of WPF (they even have a WebAssembly preview). There are of course some small differences and things not implemented yet, but the developers tend to make things as WPF-compatible as possible.

(Note that I'm in no way affiliated with the makers of Noesis, but I find their work brilliant.)

@glyad

This comment has been minimized.

Copy link

commented Jul 4, 2019

@glyad A 100% WPF implementation would require something like WINE. Thats not practical. Making a WPF subset might be possible that removes Windows specifics.

Also look up WinUI 3.0. If anything that should be ported later as its the WPF replacement for desktop (fingers crossed its done in a way porting is possible).

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

It's possible without WINE. It requires to separate code on shared and platform dependent parts (assemblies). Okey, I divine your comments regarding HWND and OS-dependent windows management, participating with Windows message loop, etc. It's exactly the sample of the "Platform" portion of code. There are two ways, how to resolve it:

  1. Do not change the public/protected interface of the Window class, just extend it with Linux/OSX options to provide back compatibility. So, will be possible to change strategy of OS dependent logic and use appropriate interface after OS detection.
  2. The breaking changes way. To remove HWND and Window messaging from Window class. So, all of platform dependent code of the application will be compiled separately from shared with respect to target OS.

Same things regarding the browser control.

@GitSrikanth

This comment has been minimized.

Copy link

commented Jul 4, 2019

Which framework best suits to develop an UI with multi-platform support - Windows, Linux, Android and iOS mobiles?

This app UI will communicate with .NET Web Server using API's.

I read some where, they suggested below links for Linux platform support.
https://github.com/AvaloniaUI/Avalonia
https://github.com/GtkSharp/GtkSharp

What I'm looking is common code base for all platform, which is best Framework to suit my requirement.
Also came to know that,
Android does not have all the Net Libraries that are in full version of Net. So the reference is saying that I must use only Net Libraries that are available on Android for code to be compatible.

I have two requirements.

  1. I need to develop an UI from scratch which runs above mentioned plat.
  2. I have already developed WPF app(with MVVMcross) that can be ported/migrated to any other framework which supports multi platform.
@zezba9000

This comment has been minimized.

Copy link

commented Jul 4, 2019

@GitSrikanth For mobile + Desktop support there is also:

  • Xamarin.Forms (looks different / native on each target platform [supports everything but the browser])
  • UWP / UNO (looks the same on each platform for the most part and supports Browser [doesn't support macOS or Linux]).
  • Blazor (Use HTML / C# in WASM. Runs anywhere a browser does. Use electron to run it on the Desktop)

For your case if you don't need browser support use Avalonia if you want everything to look the same or Xamarin.Forms if you want Win, Lin and Mac to all have a native feel and is supported by MS.

@JakeSays

This comment has been minimized.

Copy link

commented Jul 6, 2019

@Ruedii "A stripped WPF containing GDI+, MSXML, MSHTML, MSHTTP, WinSocks, Print Spool access, DirectX, TWANE and a good number of other Win32/WIn64 libraries already implemented by portable Open Source projects should be fine." - I don't think you understand what WPF is. None of those components you mentioned are a part of WPF - it is a UI framework only (although it does use some of those). You also mention a bunch of service frameworks, etc. that are not a part of WPF.

@Ruedii

This comment has been minimized.

Copy link

commented Jul 7, 2019

@popcatalin81

This comment has been minimized.

Copy link

commented Jul 8, 2019

Can WPF be made cross platform: YES
Does Microsoft want to make WPF cross platform: NO (This is the actual roadblock to cross platform, nothing else, there are no limitations or design issues which cannot be overcome).

All this discussion about APIs is somewhat funny. It's not a question of API's, it's a question of WHY. We should provide Microsoft with some "compelling" reasons to do it, not focus on technical discussions "how" to do it (BTW: lol about that). The debate on how to do it, it's quite premature.

@DaZiYuan

This comment has been minimized.

Copy link

commented Jul 8, 2019

Can WPF be made cross platform: YES
Does Microsoft want to make WPF cross platform: NO (This is the actual roadblock to cross platform, nothing else, there are no limitations or design issues which cannot be overcome).

All this discussion about APIs is somewhat funny. It's not a question of API's, it's a question of WHY. We should provide Microsoft with some "compelling" reasons to do it, not focus on technical discussions "how" to do it (BTW: lol about that). The debate on how to do it, it's quite premature.

I want to develop app using WPF and then publish to IOS/Android/Windows pc .
just like Flutter or Unity.
Flutter has taken the lead, I wish Microsoft don't give up.

@DaZiYuan

This comment has been minimized.

Copy link

commented Jul 8, 2019

If WPF is cross-platform, Strategically , Microsoft can capture more developers from other platforms . And to promote Azure . Increase the number of app for store . Improve the c# open source ecosystem. Improve developer goodwill towards Microsoft.

Microsoft has hurt a lot of developers over the years and all we need is a truly unified xaml UI framework.

@MV10

This comment has been minimized.

Copy link

commented Jul 8, 2019

I don't expect Microsoft to change their position on this because cross-platform WPF has no strategic value to them. Even though they've neglected (I'm tempted to say "wrecked") their desktop strategy lately, they still dominate the segment. We're all here because we believe WPF is a superior solution (despite its many flaws, also due to neglect), and you can bet Microsoft is well aware of that. Linux UI is a joke. OSX UI has a hardcore fanbase but it is still a tiny market. Cross-platform WPF would weaken Microsoft's position by making OSX and Linux better Windows desktop competitors. I believe you don't need to look any deeper than that.

This hasn't been an issue with other cross-platform efforts because Windows Server wasn't a leader, OSX is non-existent in the server market, and Microsoft's emerging bread-and-butter, Azure, benefits from cheap Linux servers like everyone else. Other cross-platform UI options like Electron are such crappy stand-ins for native desktop apps that they probably aren't seen as a competitive risk. (Seriously, Electron just needs to die. I can't wait to retire and never write another line of HTML or CSS again.)

@popcatalin81

This comment has been minimized.

Copy link

commented Jul 8, 2019

We're all here because we believe WPF is a superior solution (despite its many flaws, also due to neglect)

Yes, WPF is not only the best UI Library from Microsoft, it's also among the very best (if not the best) out of all UI libraries for any platform.

I think there are some compelling reasons to make WPF cross-platform.

I. Windows Azure

  1. WPF is UI Framework used by Visual Studio.
  2. Visual Studio is Microsoft's First Class Development Environment targeting Windows Azure.
  3. Making Visual Studio cross platform, will allow Linux and OSX developers first class access to Windows Azure.

II. Developers

  • Windows Developers, need a cross-platform solution. Current apps will need to stretch way more than Desktop. Phones, Tables, SoCs, Gaming Consoles, TVs are just examples where applications will need to be developed more and more. Currently developing for cross platform pushes developers away from Microsoft Ecosystem, favoring Amazon's and Google's tech stacks.

III. Windows Apps ecosystem

  • Windows Store desperately needs a boost. This may be counter-intuitive but Windows Apps being available on other platforms (Apple Store, Google Store) for User's phones and tablets, will also boost the Windows Store popularity indirectly.
@MV10

This comment has been minimized.

Copy link

commented Jul 8, 2019

@popcatalin81 Hadn't thought about the VS / Azure combo, that's an interesting point. However, I imagine it would be easier to just add Azure features to VS Code, which is already quite popular on *nix.

@tannergooding

This comment has been minimized.

Copy link
Member

commented Jul 8, 2019

Can WPF be made cross platform: YES

Yes, same anything could be "cross platform" with the appropriate abstractions/etc. The largest hurdle, IMO, is that there are a number of concepts in WPF and WinForms which are very tied to the Win32 APIs (and to DirectX in the case of WPF) that may not translate nicely to other windowing systems or graphics APIs.

Some of these differences are exposed via APIs (most of System.Windows.Interop or various properties/events/methods exposed on some of the base classes) and some of it is just observable behavior differences. For example, message processing in X11, Wayland, Win32, Cocoa, etc is all subtly different from each-other and that can impact how things flow or trigger off eachother.

Different systems/platforms also may support different window styles or resizing behaviors. For example, some platforms don't have a concept of changing the window size (mobile, small form factor, gaming systems). At the same time, you don't want to only expose things that are common to everything because that is limiting the usability for the majority of usages.

Ultimately, I think a good cross platform UX library would take these things into consideration and would expose a good common base that isn't tied to any particular framework. They would also expose the right feature detection and platform detection APIs so you can trivially light-up functionality when it is available. Apps then need to be written with that in mind as well and should be able to list features they require to run.😄

Non official opinion, thoughts are my own, etc...

@Nassiel

This comment has been minimized.

Copy link

commented Jul 12, 2019

The problem is always the same, Microsoft does things at 50% and later they'll not understand why they fail. Why Windows Phone fails, why Windows fails in servers, why Bing fails, why Azure is not as big as AWS, etc. Common, even Linux surpasses Windows in the Azure itself.

I won't consider doing WPF cross-platform an easy task, but there are no technical issues on doing it. Qt5 works even in cars or other industrial solutions (an of course in Windows), and Qt5 interfaces runs in almost every Linux desktop, and I don't say all of them because I didn't try all of them.

I agree with all the people that said that more devs will become in a richer environment, market, community. So please Microsoft, stop doing partial solutions!

Can WPF be made cross platform: YES

Yes, same anything could be "cross platform" with the appropriate abstractions/etc. The largest hurdle, IMO, is that there are a number of concepts in WPF and WinForms which are very tied to the Win32 APIs (and to DirectX in the case of WPF) that may not translate nicely to other windowing systems or graphics APIs.

Some of these differences are exposed via APIs (most of System.Windows.Interop or various properties/events/methods exposed on some of the base classes) and some of it is just observable behavior differences. For example, message processing in X11, Wayland, Win32, Cocoa, etc is all subtly different from each-other and that can impact how things flow or trigger off eachother.

Different systems/platforms also may support different window styles or resizing behaviors. For example, some platforms don't have a concept of changing the window size (mobile, small form factor, gaming systems). At the same time, you don't want to only expose things that are common to everything because that is limiting the usability for the majority of usages.

Ultimately, I think a good cross platform UX library would take these things into consideration and would expose a good common base that isn't tied to any particular framework. They would also expose the right feature detection and platform detection APIs so you can trivially light-up functionality when it is available. Apps then need to be written with that in mind as well and should be able to list features they require to run.😄

Non official opinion, thoughts are my own, etc...

@Ruedii

This comment has been minimized.

Copy link

commented Jul 19, 2019

@zezba9000

This comment has been minimized.

Copy link

commented Jul 19, 2019

DirectDraw? WPF for Win95 here we come!

@Ruedii

This comment has been minimized.

Copy link

commented Jul 20, 2019

You seem pretty overconfident and lacking of full understanding of Win32/Win64 underlayer. Don't worry, it's common when you just trust Microsoft and don't look behind the curtain of the front layer APIs like WPF.

The DirectDraw API is still part of DirectX API. It's non-depreciated subset was greatly reduced in version 8 and 9, and packaged together with Direct 3D. It's then remained largely unchanged on the API side after that.

It provides 2D vector and raster routines when rendering to a fixed memory buffer.

It is still a separate DLL file, but most drivers no longer provide a native interface, instead relying on a shader-based implementation included with Direct3D 9.2 and later. On the other hand, most portable implementations implement this directly to their OpenGL based rendering underlayer, because there is no point in running through two graphics conversion layers.

@zezba9000

This comment has been minimized.

Copy link

commented Jul 20, 2019

Lol ya um no. Its pretty thick you didn't get the joke (which is how I intended it NOT as an attack).
I've used just about every rasterizing API there is. Also your GL statement is a false premise for a proper platform agnostic rendering abstraction API layer. I don't trust MS to do this right and is why I'm working on portable C# APIs that help solve issues like you brought up. O and guess what DirectDraw will be supported because I like targeting legacy targets as well. I thought it was funny/cool you even mentioned it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.