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

[dotMorten]

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

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

Please at least be open to discuss these.

[10Dev]

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]

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]

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

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

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]

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

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]

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 :1st_place_medal: :100:

[HumanEquivalentUnit]

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

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

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]

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.

[legistek]

It's amazing to me how some people think open source means they get to demand that the maintainers do whatever is asked of them with no right to pursue their own strategic agenda.

Microsoft didn't have to open source WPF at all. I'm extremely glad they did. I've wanted cross platform WPF for many years. (Not Avalonia; not Xamarin.Forms (though I am a fan of that too); I wanted to be able to take my existing WPF apps and simply recompile them to other platforms).

The only thing that was impeding that from happening was the closed source license (the reference source was always public, but it was not licensed to make derivative works). Now that that barrier is gone, cross-platform WPF will eventually happen. Whether Microsoft bankrolls it is a different story. I don't see Apple or Linux Foundation investing much in Windows app development...

All that aside, I think the difficulties in making WPF cross platform might be a smidge exaggerated. I've studied the aforementioned reference source extensively. The overwhelming majority of it does not depend on Windows, because unlike Windows Forms, as we all know WPF handles all the rendering from the top level window on down.

And when you think about it, WPF was architected to be cross platform, and we know this - why? - because of Silverlight! Remember, Silverlight ran on MacOS eons ago. So we know it can be done. Trivial? No. Doable? Absolutely. So now the community can take a stab at doing it finally and will start out 90%+ of the way there.

[4creators]

@legistek Very good point indeed.

For a while I was afraid that MSFT will decide to keep WPF as closed source what would make any work in making xplat support for WPF/UWP based .NET UX platform much more difficult. I fully understand MSFT position due to currently insignificant market share of Linux desktop and availability of recently aquired Xamarin xplat mobile framework. It does not make sense for company to double invest in xplat UX which would mainly target mobile devices.

However, it is different story with FOSS community. MSFT enabled us to make WPF/UWP cross platform and it is up to community to get it done. Since none of the UX repos would accept any code for xplat support we have no choice but go for it in independent fork. I would not be surprised if some folks from MSFT would join such community effort on their own though.

There is long lived thread https://github.com/dotnet/designs/issues/12 which is used to track this issue where we received clear answers from dotnet maintainers @jkotas and @AdamYoblick how community should proceed. We should work in community forks and since all CI infrastructure is or soon will be based on Azure DevOps we could leverage free open source offerring https://github.com/dotnet/designs/issues/12#issuecomment-444563442.

I have created organization DotNetUX and forked wpf, winui, winforms repos there and plan to work on porting wpf/winui to macOS and Ubuntu by leveraging already existing oss libraries with DirextX translation layers to vulcan and metal. If anyone wants to join the effort and shape it's goals pls ping me.

By any means I am not trying to be the lead of team working on such project nor the lead developer. I am ready to share or even transfer ownership of this repos/organization to recognized open source foundation or organization with wide OSS community representation. By living up to the standards of oss communities I would like to participate in a community where every actively contributing member would have equal rights with regard to determining project directions and accepting commits.

[zezba9000]

@legistek @4creators I agree, the difficulty of porting WPF seems exaggerated (while it would take some time). You just have to replace some Windows only dependencies with platform agnostic ones.

The major breaking changes that would need to happen or I say should happen is:

1) Replace D3D rendering back-end with an agnostic graphics API that can target D3D9-12, D2D, Vulkan, GL, GLES, Metal, etc. Any open source frameworks like Telerik or whatever that depend on D3D could just get ported at some later date to the newer platform agnostic graphics API this folk of WPF is build on.

2) The HLSL lang used for shaders could get replaced with C# syntax using Rolsyn to transpile a C# subset to different GPU program targets like HLSL, GLSL, CG, etc for maximum portability which also allows for a better degree of control and familiarity.

3) Other aspects like MessageBoxes and most other commonly used WPF features etc from an API point of view would be 100% or near 100% the same as just the WinAPI part need to be made agnostic on the backend.

In short you may want to think of this WPF version as you think of .NET Core to .NET Framework. They are largely compatible but some critical frameworks and moving parts need to be changed to make it run smoothly on more platforms.

[juanfranblanco]

@glyad i have by no means any relationship with Avalonia, so no advertisement, but after evaluating for ages many cross platform solutions, and knowing how difficult will be to implement WPF, the closest solution is Avalonia. Up until now the WPF internals were not available, now you actually have the possibility to use them to make a compatible layer with something like Avalonia, which aims to be very similar to WPF. Also we could start talking about the Xaml Standard, but that did not go anywhere. Why duplicate when you can collaborate an enhance.

[kekekeks]

make a compatible layer with something like Avalonia

I'm planning to take a shot at compatibility layer once the entire code base is available. I believe it could be done without modifying the code base by replacing some classes with shim implementations using MSBuild only. That could live as a repo that uses WPF as a submodule, so keeping the source in sync with this repo should be easy.

The thing is that our DrawingContext API is almost identical to one in WPF, so wrapper would be rather thin. I'll have to add a partial class to make System.Windows.Controls.Control to implement IVisual. That would allow to render WPF control hierarchy using existing Avalonia rendering engine.

Window class and PresentationSource would most likely need to be rewritten completely. The input system could also live as a compatibility shim.

Our layout and input systems are really, really close, you can take a look at our embedding to WPF implementation here. We are using D3DImage/WritableBitmap for rendering, but that boundary isn't needed if we are in control of the rendering system.

Said compatibility layer would allow to mix and match WPF and Avalonia controls.

[glyad]

@juanfranblanco, thank you for your answer. I'm sorry for my sentences with "advertising of Avalonia".
Anyway, the key question is about of the compatibility on a level of the public interface with current version of WPF framework, e.g. can I compile my existing WPF sources with another WPF-like framework, like as Avalonia, or not.
I started to develop with WPF at 12-03-2006. Since December 2006 I developed, architectured, consulted more, than 100 projects in Israel. At least part of them is still in life till now, but no company will rewrite tons of code (+XAML). There is the only way for WPF future and this way is to become cross-platform preserving full compatibility with public interfaces. If Avalonia can answer to this qestion , it's welcome!

[juanfranblanco]

@glyad don't worry I fully understand, companies won't invest if they don't see a clear future of the platform as a whole (ie cross platform), even if 90% of their users will remain in Windows.

[kekekeks]

@glyad
"Full compatibility with public interfaces" will never happen, because public interfaces aren't cross-platform.

A notable example would be PlacementMode enumeration for popup. It has Absolute and AbsolutePoint values that need a way to position the popup relative to screen coordinates. In Wayland protocol which is now replacing X11 there is no such concept as "screen" coordinates. You can only have some kind of positioning rules that allow to place your popup relative to some other surface (window or popup). If you are relying on absolute window coordinates (like AvalonDock) that won't work either.

WebBrowser control is tightly coupled with internet explorer in-process engine. Even if one would somehow implement the entire DHTML COM API on top of Chromium, modern web browsers have their javascript and rendering in a separate process.

WPF allows you to run UI on any thread. There is no way you can do this on OS X with Cocoa. So all your code that creates windows from background threads simply can't work on Mac.

Anything you are doing in overridden WndProc will simply won't work. Mono has tried to emulate window messages that are going through WndProc for their managed WinForms implementation and that ended poorly.

There are also tons of WinAPI-specific and ActiveX-related stuff that can't be portable.

The list goes on and on.

Basically, the only thing you can get is some Silverlight-like subset of API. We can do some kind of compatibility layer on top of Avalonia that allows to run 80% of WPF views, but that's it.

[glyad]

Thank you @kekekeks,

You're right. I fully understand the issue with constrains mentioned. Yes, it looks impossible to port some things in their current meaning as is. Could you agree that VS-like (AvalonDock-like) UI is possible on Wayland? So, it's about an issue with platform dependend definitions of things.

The example with browser was really great! The browser control was based on IE7 (I don't remember exactly). It was showstoper for many usage scenarios with modern html/js content. I solved this problem in following way: (1) detect the latest installed version of IE com server, (2) instatiate the IE component in borderless window (3) create my own window z-index manager (4) show IE component's window on top of the owner window, (5) change position, sizing, and visibility of IE hosing window in concequence with behaviour of owner window. It's all about how to render some things on various platforms.

Issues with coupling to Win32 and COM API's are more complicated. I also think that most of them aren't resolvable. OK... There are platform constraints for full compatability. Probably, for the part of them may be possible to find implementational work-arounds.

You wrote "Basically, the only thing you can get is some Silverlight-like subset of API". YESSS! Silverlight 5 was the best candate to make great cross-platform UI framework. We developed desktop level applications srarting from using of versions 4 and 5 of Silverlight. I think, need to continue with SL5 way to achieve "portable WPF".

Regards,

[kekekeks]

Could you agree that VS-like (AvalonDock-like) UI is possible on Wayland

Yes, but AvalonDock will have to be reimplemented to use drag-n-drop instead of tracking window positions.

The problem about WebBrowser is ObjectForScripting and Document properties. It's expected that they allow JS code to interact with C# and vice versa. That won't work property because of multiprocess architecture of the modern web browser engines where web content runs in a separate process in sandboxed environment.

I think it should be possible to run most of the xplat controls on top of existing Avalonia rendering engine. Flow document model might be tricky since we haven't quite yet finished our own one (still struggling with text layout engine on top of Skia). Viewport2D currently can't be supported since we don't have proper integration with OpenGL yet.

[popcatalin81]

I would really love WPF on Raspberry PI ... it would be the dream.

[valeriob]

Someone else is doing the most promising xplat ui toolkit, and it's not Xamarin :(
https://youtu.be/D-o4BqJxmJE?t=538

[raffaeler]

It would not make sense for Google to promote a Xamarin based solution given the size of the package and the problems the community is meeting. Xamaring can work decently for business apps, but IMO is certainly not a general purpose solution.

[valeriob]

It would not make sense for Google to promote a Xamarin based solution given the size of the package and the problems the community is meeting. Xamaring can work decently for business apps, but IMO is certainly not a general purpose solution.

Yea ofc, i mean it's sad that google is tackling the problem and not Microsoft.
I'm not saying that WPF should be that solution, it's just that i see a big opportunity not being perused by Microsoft. Google is preparing the road for THE native platform to develop native application for, so they will be able to innovate Android (with Fuchsia of whatelse on the desktop). Microsoft is not doing anything in that regard, meanwhile they dropped Edge, so google is going to control the developer space in the future with this trend.

[raffaeler]

It is sad indeed.
There have been multiple occasions in the past, but they tried to force UWP adoption with the 'Windows only' restriction which is a no-go since a long time.
The currently most widely adopted solution is Electron which has the big advantage to reuse web skills (it's hard to find a XAML developer, far more easier an html/css one).

[dotMorten]

would really love WPF on Raspberry PI ..

You can already run UWP-based xaml apps on them. Performs better too

[zezba9000]

would really love WPF on Raspberry PI ..

You can already run UWP-based xaml apps on them. Performs better too

UWP on the Pi doesn't use the GPU. Linux is way faster in every area on those things.

[dotMorten]

Use a dragonboard instead and you'll get full DX acceleration

[zezba9000]

Use a dragonboard instead and you'll get full DX acceleration

I have one (they're cool), still slower than using Linux on a PI with GPU acceleration that requires way less power to do the same thing and cost a lot less too. More bang for your buck when you use GNU Linux and a lightweight compositor :)

[Nassiel]

I don't really get the point of developing WPF for a cross-platform .net framework and develop it as a non-cross platform.
I could understand that WPF depends too much on DirectX... but we already have the standard.net for that, why a new one which do the same? This one should be based on OpenGL to make it truly cross-platform.
But, well I just hope you'll recapitulate.

[KodamaSakuno]

I don't really get the point of developing WPF for a cross-platform .net framework and develop it as a non-cross platform.

The original .Net Framework is dying, it's hard to get more features which .Net Core has at the same time. By moving to .Net Core, desktop apps can get much benefit from .Net Core with new APIs, language features and performance improvements.

[kekekeks]

This one should be based on OpenGL to make it truly cross-platform.

For your information OpenGL is deprecated on Mac OS X and the support for it will be removed in the future.

[zezba9000]

This one should be based on OpenGL to make it truly cross-platform.

There is no such thing as a fully "native" cross platform graphics, audio or input API. There are always some platforms that don't support one vs the other because of hardware or OS reasons. You have to use agnostic APIs / standards that sit on top of these fragmented layers.

[feliwir]

Like https://github.com/mellinoe/veldrid

[lindexi]

@feliwir lc-soft/LCUI: A small C library for building user interfaces with C, XML and CSS.

[popcatalin81]

I don't think this discussion should be about cross-platform XAML, XML or others, because already are sensible solutions there.

This thread should be about cross-platform WPF specifically. Why WPF and not xaml, because there is a huge investment in WPF, apps. controls, libraries, which would benefit from the migration. It's not about the transfer of skills (and XAML is not that complex anyway), it's about the transfer of existing investment and providing a clear and unambiguous path into the future for WPF specifically.

[lindexi]

@popcatalin81 Do you mean https://github.com/Microsoft/xaml-standard?

[Nassiel]

This one should be based on OpenGL to make it truly cross-platform.

For your information OpenGL is deprecated on Mac OS X and the support for it will be removed in the future.

OpenGL, Vulkan, or similar graphics platform. The key point is creating on top of a cross-platform framework, something non-cross-platform. Even when people offered to develop the enormous work of making it cross-platform, the actively denied it.

[Joebeazelman]

A cross platform WPF would be nice, but I think what most people here want is a XAML-based cross platform UI engine. Microsoft claims it can't deliver one because it is too hard. I just don't buy it coming from one of the largest corporations in the world.

Microsoft had SilverLight (XAML-based) running across platforms years ago by targeting low-level platform graphics primitives. Miguel and his tiny team were even able to port it to Mono as Moonlight. Microsoft senselessly killed SilverLight, allowing for the continued tyranny of html/css. Later they introduced Windows 8 and demanded developers use WinRT, creating self-inflicted FUD. Developers became unsure of Microsoft's roadmap concerning not only WPF, but .NET itself. Microsoft never gave their official position, further alienating their developer base.

Thanks to those idiotic moves, Microsoft now finds itself playing follow the leader with Google and Apple leading the future. Windows desktop developers, with no modern UI platform to hang their hat on, switched to the browser or Qt for more demanding graphics development. Since they already switched to UI engines, they might as well switch languages, IDEs and even platforms. Usher in mobile devices, in which Microsoft lost badly, Windows-only development is now nonsensical. UWP was Microsoft's ill advised disaster recovery. UWP is a least common denominator UI engine, enforcing a limited, mobile-centric UI on the desktop.

Microsoft is running around frantically looking for relevance. It embraced open source and spent $7 billion to buy GitHub just to win back developers. While Windows mobile and Windows 8 was devastating, the self-inflicted FUD surrounding WPF has made it far worse and unrecoverable. All Microsoft has now is Azure, business applications and a small and dwindling Windows user base. All these markets are up for grabs by competitors.

[MV10]

@Joebeazelman The Windows userbase is hardly small or dwindling, but you pretty much nailed it, otherwise. I want to gag every time I see some web-blind dev gush about Electron or some other browser-based garbage. I read somewhere that MS had close to a thousand people working on the original WPF. The OSS+netcore thing is nice, but they need a big push to modernize it, they need to dogfood it, and xplat might be the eye-opener they need.

.NET Core's history has been "We aren't going to do that," then a year later they're doing it, so maybe there's still hope. I recently led a push in my own company to switch back to native Windows apps, but sadly it's going to die because of the sheer momentum behind web apps. But it was amusing to see how shocked web-only devs and non-technical managers were at the performance levels possible with a native Windows app. Kids these days...

[SamuelEnglard]

.NET Core's history has been "We aren't going to do that," then a year later they're doing it, so maybe there's still hope.

More "under promise and over deliver", which is better than Longhorn 😒

[zezba9000]

@MV10 " I want to gag every time I see some web-blind dev gush about Electron or some other browser-based garbage."
-- I'm in this boat as well. HTML/JS/TS suffers from issues MS-XAML fixed over 10 years ago.... its a sad joke people have been forced to go down that bug prone path. Non Type-Safe UI isn't a good idea.

[Joebeazelman]

@MV10 Perhaps 'dwindling' maybe a bit strong, but the momentum has been building for sometime against Windows. Back in the late 1990s, Apple was left for dead and you'd be considered a fool to think Microsoft Windows would ever lose marketshare to any competitor, especially Apple. Fast forward a couple of decades later and behold the most spectacular comeback story ever told. Apple's marketshare across laptops and desktops were in the 2% to 3% range around 1999. Today it has reached roughly 9%. As for consumers alone, it may be even higher.

I abandoned Mac development two decades ago after falling in love with .NET and my dislike of UNIX, but I recently purchased an older model 2014 MacBook Pro and it has blown me away with the shear productivity increase. The idea of starting this comment on my iPad at home and then finishing it on my laptop at Starbucks while also texting my wife and facetiming my kids on both is surreal science fiction to say the least. I've seen tons of sales and service workers using iPads and iPhones as their primary device and they love it. It is surprising Apple hasn't positioned their products for the business market as clients for their enterprise server apps. It's probably on their secret roadmap.

While windows was once the 800 pound Gorilla, today it is merely a 600 pound one being challenged by younger alpha males. The growth in the desktop market has been slowing over the past five years. Windows 10 is less than half of the market with many users refusing to upgrade from Windows 7. Businesses are trying to save money by off-premising their applications and using lighter weight clients. This is a very different scenario from what it was a decade ago.

[lindexi]

Can we bring the WPF to the modern browser by WebAssembly? Maybe it can barely be considered cross-platform.

The long long years ago, we can build a WPF web application but our customers should install some application to support it.

But I still do not think it a good way.

[lindexi]

Maybe the xaml can be cross-platform like the HTML and C# can be used in the browser by WebAssembly that we can write a web page without HTML and js and we can use xaml and C# to write a web page.

But I sure it is not WPF.

[MV10]

@lindexi See http://www.cshtml5.com/ ... not exactly what you describe, but headed in that direction. However, I think it would be a crying shame to bog down WPF/XAML with the dumb-terminal overhead of a browser environment. The browser isn't an OS. People need to stop trying to shoehorn everything into a fundamentally clumsy client-server document-viewer paradigm.

@Joebeazelman The Win7/Win10 thing is history at this point (for example, article). Microsoft has always been terrible when it comes to marketing (and related things like overly complicated product "levels" and licensing packages and so on), and that's really what Apple and Google have exploited. One thing I suspect we can agree upon: MS needs to get their butts in gear and focus on their enterprise base -- the majority of Windows users sit at a keyboard, not a tablet, and they are most likely there to work. And in the enterprise environment, IT owns the desktop and the servers, making it the perfect place to leverage native Windows apps.

You start showing users that Windows apps are blazingly fast compared to browser-based script-junk and it just might drive a general demand for better UI/UX experiences. Although I must sadly concede that it's entirely possible they've already missed that boat.

[lindexi]

@MV10 That is a good idea.

[walterlv]

@MV10 The CSHTML5 seems to be a good solution for me to try. Thanks.

[mohamedmahmoudalemam]

WPF is one of the best GUI frameworks in the world, It must be Cross platform, It must be.

[chrpai]

Can someone explain to be why VS2019 has a WPF .Net Core 3.0 project type? I built one, ran it on windows no problem and then tried to run it on a Mac and got an invalid runtime message. I really need a way to write multiplatform native desktop applications using C#/.NET/WPF. I'm tired of everyone always choosing web app and/or electron app because we don't have the tools in our stack to get the job done.

[popcatalin81]

Can someone explain to be why VS2019 has a WPF .Net Core 3.0 project type? I built one, ran it on windows no problem and then tried to run it on a Mac and got an invalid runtime message.

Yes, guys please start explaining this. You'll have lots of people to explain it to.

[SamuelEnglard]

Because .NET Core doesn't mean cross platform? It just means runs on the .NET Core runtime using the .NET Core framework?

See https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/ and https://devblogs.microsoft.com/dotnet/announcing-net-core-3-preview-1-and-open-sourcing-windows-desktop-frameworks/

[MV10]

Because .NET Core doesn't mean cross platform? It just means runs on the .NET Core runtime using the .NET Core framework?

.NET Core _is_ cross platform but WPF isn't part of .NET Core, it's an add-on.

[SamuelEnglard]

Yes, .NET Core itself is cross platform. Libraries and applications written using .NET Core do not have to be though.

[chrpai]

Understood. What I'm trying to ask is WHY strategically / tactically I would choose .NET Core WPF over .NET Framework WPF when either way it'll only run on windows? Am I hoping for a one day future where it'll run somewhere else? I ask because I have an open source Winforms app that I'm porting to WPF MVVM and would love to go multiplatform one day.

[raffaeler]

@chrpai one of the values of .NET Core is the ability to run multiple versions truly side by side.
Also, you can ship your app together with all the requirements (including the CLR itself) when deploying as "self-contained deployment". There are tools (coming with netcore 3.0) that will give you the ability to ship a single exe. For details, read here:
https://devblogs.microsoft.com/dotnet/net-core-3-and-support-for-windows-desktop-applications/

[zezba9000]

@chrpai .NET Core is faster and supports newer frameworks and features. .NET Framework 4.8 will probably be the last major version of that runtime and library set.

[johngsandiford]

MS probably want to ditch the original framework going forward in favour of core + we have found core to be 20% faster in many cases, so you get a massive perf increase even with wpf on windows. Unfortunately it does lead to a lot of confusion. However, we are now using 80-90% of the same code base with our wpf code and our new cross platform razor components (+wasm if promoted) which is exciting.

[DaZiYuan]

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

[Atulin]

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]

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]

@DaZiYuan Try Xarmain

[DaZiYuan]

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]

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

[Ruedii]

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]

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]

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

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]

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

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]

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

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]

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

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

Sorry I meant that as a batch list pertaining to all Win32 specific
frameworks, not just WPF. I sort of dropped the and other frameworks part
from the message.

However, as I mentioned all of the specified APIs have open source
implementations available.

On Sat, Jul 6, 2019, 7:02 PM Big Jake [e-mail] wrote:

@Ruedii https://github.com/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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2PCGSJZI3WXYGUCMNLP6EQABA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZLBTAI#issuecomment-508959105,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYFL2NY7E2WRE7UOPIYGATP6EQABANCNFSM4GIETR6A
.

[popcatalin81]

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]

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]

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]

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]

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]

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

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]

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]

The only reason I'm interested in cross platform WPF is to make it easier
to port applications already using it. I have little interest in using it
on my own projects because other GUI frameworks with far better cross
platform support exist.

That said there are several portable versions of Direct3D, Direct Draw,
GDI+ and most other APIs. I think Microsoft is just too proud to go from
sueing these projects to using them.

This pride is why they continue to be behind the curve. Instead of
admitting when the community developed something good, be it a standard, a
library or a whole OS, they go and stick to their old stuff and live in a
world of denial where desktop market share somehow implies superiority.

On Fri, Jul 12, 2019, 4:58 AM Nassiel [e-mail] wrote:

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

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2M472CWE6CPGKQ2PNLP7BBSVA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZZFLHA#issuecomment-510809500,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYFL2KDXBPZL4Z7Q7QRDD3P7BBSVANCNFSM4GIETR6A
.

[zezba9000]

DirectDraw? WPF for Win95 here we come!

[Ruedii]

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]

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.

[LeoYang-Chuese]

The blog launched this survey on August 7 to see if Microsoft is also listening to the public to seriously consider the.net cross-platform desktop development framework.
calling-all-net-desktop-and-mobile-developers

[sunliusi]

I think ms wants to keep its desktop market, and unless Microsoft's desktop market fails, there will be no cross-platform wpf.

[QuAzI]

It would be nice to have something like Rendering Hardware Interface (RHI) in Qt6 to have really cross-platform software.

[lindexi]

@QuAzI I do not thinks it a good way to render to special platform

[zezba9000]

@lindexi Actually if I understand QT RHI correctly thats exactly how you do it. Just as you abstract input and audio layers, so do you with graphics. This is a fundamental concept in game engines... and they're usually pretty portable if done correctly.

[Ruedii]

It's not to a "special platform" but a way to allow rendering to any
platform with minimal coding.

This includes all major mobile platforms, plus current and future console
programs.

Personally, I'd prefer using a cross platform API like OpenGL or OpenGL ES
to handle rendering, but having an abstracted layer to implement doing this
would be ideal because one could add support for other rendering paths as
well and with CIL Runtime Bytecode, the library will work the same
regardless of the back end on the system.

Ideally we should make a backend canvasing system with passthrough of a
generic SLang shader dialect. This would permit any .Net UI platform to
draw through this API.

[weltkante]

Apparently Microsoft decided to not open source PresentationNative, the component for the text processing of WPF. Any attempt to make WPF cross platform will have to reimplement the text processing from scratch.

[weitzhandler]

There is the Uno Platform that renders UWP XAML and C# to Windows, Android, iOS, and even WASM-web, all from a single code base.

[JakeSays]

@weitzhandler Uno is promising but there's two issues I have with it
1) no linux support
2) it uses platform native UI instead of rendering itself.

[MV10]

My guess is they expect Blazor + Razor Components to wipe out desktop apps. Not that they perform like WPF can, and there are many severe restrictions the browser sandbox will bring ... but that's where the focus seems to be now. That wouldn't be as sadly inadequate as traditional web apps lurching into the desktop space via hacks like Electron, but still pretty limited.

[weitzhandler]

@JakeSays

1. no linux support

Looks like Linux has been on their radar for a while, and they're now working on making it work as a PWA, meaning it's gonna work on Linux as well soon, via WASM.

2. it uses platform native UI instead of rendering itself.

They do, but unlike other platforms, Uno renders the same everywhere. That enables you to either deploy your app to render the same everywhere, or if you would choose to, apply a specific theme to each platform to apply a native look and feel. Some (myself included) would see taking advantage of the native UI controls as a plus.
You may want to check out AvaloniaUI, which renders on linux, and has its own renderers, tho no wasm support, and mobile support is experimental.

@MV10

My guess is they expect Blazor + Razor Components to wipe out desktop apps...
... but that's where the focus seems to be now

Yeah unfortunately so it looks. Blazor is based on HTML & CSS. To anyone who's ever used XAML, HTML & CSS will always be class B.

[JakeSays]

1) I don't consider a PWA as a solution. That's just a web site in a box.
2) How is that possible? If Uno is using native widgets then it's not going to look the same everywhere. Also avalonia's focus has been on using native widgets. They do have their own renderers but they are seriously lacking. Avalonia is also far from production ready. wasm support is of no interest to me.

[zezba9000]

@JakeSays I'm working on some foundation peaces that will make what you're talking about possible. Including cross-platform shaders that can be used in UI written in C# code. Easy yet powerful graphic, audio and input abstraction layers are a prerequisite for a proper UI system in my view as well. I have a good understanding of how to do this, just takes time.

[weitzhandler]

@JakeSays on Oct 2 2019
1. That's just a web site in a box.

Semantically you're right, but when that 'website' is WASM, it performs with native speed.

2. How is that possible?

They render the native controls to look the same everywhere, so you can style/theme your app in one place.

Besides that, if WASM and web is of no concern to you, Xamarin.Forms has preview support for Linux (read this).

[JakeSays]

It's not native speed. Wasm is JIT'd, yes, but there is still a ton of overhead involved with interacting with the platform (browser). And anything browser based is a major resource hog. It's hard to justify shipping an operating system (chrome is basically a web operating system) with your app.

So does Uno use platform native controls or does it not? "they render the native controls the same everywhere" is extremely confusing because I'm not aware of any native controls that can be skinned/themed enough to look the same everywhere. So either they are using native controls and you get platform look & feel, or they don't use native controls, render everything themselves, and have full theme support.

Also, xamarin linux support is built over gtk, so it still uses platform widgets. I want something that does all of it's own rendering just like WPF. WPF doesn't use any of the win32 native controls, etc. This is why xplatform WPF is so appealing.

[JakeSays]

@zezba9000 what are you using for your graphics stack?

[zezba9000]

@JakeSays A custom platform agnostic rendering API (that will be open source under MIT). Think XNA in the sense of easy to use and understand yet more powerful and highly efficient. The API will support D3D9-12, D2D, GL, GLES1-3, Vulkan, Metal, Software-Rasterizer, Custom-Rasterizers, etc, etc and run on Linux, macOS, Win32, WinRT, RPi, etc, etc. Basically anything. Custom GPU Shaders can be written in C#. This is something I have good understand of and I've done in the past with something called the ReignSDK but the new version will be much much improved.

Same concepts used to do graphics also apply to input and audio. The foundation peace I'm currently working on is called "CS2X" https://github.com/reignstudios/CS2X

That will be used for the cross-platform C# shader compiler. From there everything falls into place rather well.

[JakeSays]

@zezba9000 Why don't you just use skia? You get all of that for free, and you can focus on the secret sauce - the design of the rest of the UI platform. Think avalonia done right. I do however like the idea of c# shaders. I believe microsoft did a research project around that idea.

[zezba9000]

Because Skia is not the same thing as what I'm talking about really nor does it support 3D. It doesn't even target WASM or WinRT or many other systems. Skia also doesn't solve the problem of having 3D objects in UI. This is a very large conversation that goes into desktop app UI, to browser UI, to game UI, to game engines, to common desktop, mobile and web apps.

What you're suggesting is the fundamental problem with many UI systems or game engines right now. Locking yourself into one IP that itself is to locked into other IPs as it becomes harder and harder to port.

Anyway I probably shouldn't have even brought it up in some ways as until I'm closer to demoing working stuff...

[JakeSays]

Ah I thought we were discussing a UI framework, not the kitchen sink. I have no interest (nor do 95% of the rest of the developers needing to get their job done) in game engines or 3D.

And skia does target WASM and does support WinRT.

I was excited thinking you were working on an actual UI framework.

Anyway, good luck with your endeavor.

[mdtauk]

There are those who want to build a single app UI with WPF, with a Windows/Fluent look, and have it run identically on MacOS and Linux. (Formally done with Silverlight in a browser)

Others want to declarative mark up a semantic UI, but allow the Native platform to define the visual style and rendering of the app. (Xamarin)

And Microsoft seem to believe that backend code sharing is what people want, and let them make bespoke UIs for each platform. (.Net Core)

---

My thoughts - which I have expressed previously in other discussions for the WinUI 3.0 project - have been to try to separate the renderer from the markup. This would probably require a translation layer, or rendering API.

• That way the community could develop a Metal renderer for macOS, iOS, etc
• A Kotlin version for Android
• And Microsoft can continue to manage it's DirectX renderer.

[JakeSays]

@mdtauk kotlin is a language, not a rendering api. Separating markup from rendering is fairly trivial - you can write entire WPF apps without writing a line of XAML (I call it WpfForms. lol), and if you are a masochist you can create an entire web site without writing a single line of html or css.

And I'll say it again, skia provides everything one needs for the rendering stack. It's portable everywhere, supports OpenGL/EGL, vulkan, and I think metal as well. All the primitives one would ever need for a UI framework are present. It doesn't make sense to spend time on that area.

[mdtauk]

@mdtauk kotlin is a language, not a rendering api. Separating markup from rendering is fairly trivial - you can write entire WPF apps without writing a line of XAML (I call it WpfForms. lol), and if you are a masochist you can create an entire web site without writing a single line of html or css.

And I'll say it again, skia provides everything one needs for the rendering stack. It's portable everywhere, supports OpenGL/EGL, vulkan, and I _think_ metal as well. All the primitives one would ever need for a UI framework are present. It doesn't make sense to spend time on that area.

Quite right, it would be a C/C++ renderer, and as you suggest Skia is low level enough to fill in for that.

That still requires WPF and WinUI to be opensourced and architected in a way, that allows a substitution of rendering for each platform.

[JakeSays]

Skia provides the rendering. It manages all the graphics related platform abstraction, so there would be no need for substitution.

But as far as WPF and WinUI are concerned, I really think this would have to be a community effort without the support of Microsoft. I don't think they want to commit the resources (which is fine).

[mdtauk]

Skia provides the rendering. It manages all the graphics related platform abstraction, so there would be no need for substitution.

But as far as WPF and WinUI are concerned, I really think this would have to be a community effort without the support of Microsoft. I don't think they want to commit the resources (which is fine).

At present, WPF and WinUI use Direct X to render on Windows.

You would need to cleanly separate the rendering from the Markup Parsing. Then you will need to make a renderer using Skia drawing commands - and some elements like the Windowing, would need Linux and Mac specific code - so window controls, and visual styling is applied in a way that allows the WPF UI to display correctly.

As long as the rendering remains Direct X, and there is no way to compile for Linux and Mac using platform specific rendering - this will not happen within the framework itself.

[JakeSays]

I guess my point is markup parsing is already very abstracted from rendering. It's also a very small part of the entire stack. The windowing support can done in a platform independent way (there are several toolkits for just that sort of thing).

I was really hoping MS would release the native bits to WPF. I was going to experiment with porting them to wine's DX implementation.

[zezba9000]

@JakeSays You're misunderstanding. Yes I will be making a XAML UI that is based on a agnostic rendering API. However desktop application UI principles are interchangeable with game UI when it comes to event systems and game UI is interchangeable with desktop application UI when it comes to visualizing complex 3D data-sets in your application. Which I've needed in multiple jobs.

The UI system will support games and desktop applications and the foundation of all this is ideal for both. Simple put, the modularity of the APIs are not bound to any particular platform or application type. I was simply sharing part of what will make it so portable.

Also unless mistaken Skia does not run in WinRT or WASM (this is Avalionia's issue with it) without using a 3rd party port as its built on top of OpenGL. That is fundamentally different from just being able to replace the rendering backend without needing to fork the entire code base introducing fragmentation or future portability and compatibility issues.

[JakeSays]

@zezba9000 https://skia.org/user/modules/canvaskit - wasm. It is also possible to use skia compiled to wasm via emscripten. Skia isn't GL exclusive. It also support vulkan, but for wasm, translating EGL -> WebGL is fairly straight forward and makes the most sense. Also I have personally run skia in a WinRT application. I am not sure what the avalonia guys are talking about.

Look - all I want is one UI framework that is truly cross platform without depending on platform native controls, etc, and that has nothing at all to do with HTML. Whether or not I can swap out rendering, etc doesn't matter because it offers little value when all you need to do is develop line of business UI's across multiple platforms, that look and act identically everywhere.

A cross platform WPF would do exactly what I need.

So far the closest I've found is flutter, which is actually a fantastic framework. It's only flaw is dart.

[mdtauk]

I believe Flutter for Windows is currently being worked on I believe.

The Windows shell is in early stages. It is Win32-based, but we plan to explore UWP support in the future.

Expect the APIs for the final shell to be radically different from the current API surface.

https://github.com/flutter/flutter/wiki/Desktop-shells#windows

[JakeSays]

@mdtauk yes it is. I've been porting flutter to several embedded devices over the past few months. I'm really impressed with its implementation. Google did a good job.

[mdtauk]

React Native for Windows may be a better fit eventually, if you don't want to be locked into Dart

[JakeSays]

I'd much rather use dart than javascript. Dart is actually not bad. I plan on doing an experiment with replacing dart with C#.

[zezba9000]

@JakeSays Yes I've seen that WASM port but was under the impression it wasn't as featured. Was your WinRT test using the GPU or CPU to rasterize objects? Either way its not like I don't like Skia its that it simply doesn't solve many of the problems I'm trying to solve (and thats to much to get into here). I plan on also being able to target embedded devices with no OS for example as well.

I'm in your boat though when it comes to desktop apps. Its been a C#/.NET issue for as long as I can remember... MS is shooting themselves in the foot with all this. At least WinUI 3 will solve some issues if your only target is Windows and if that is designed right it might be possible to port it to Linux.... but thats a big if. HTML is not a valid solution for many apps.

[JakeSays]

@zezba9000 It was using the gpu via ANGLE - I was experimenting with running flutter on WinIOT.

[kekekeks]

@JakeSays

Why don't you just use skia?

The problem with Skia is that custom shaders have to be compiled alongside with the native library. They are using SKSL that gets compiled into C++ and GLSL. So it's not really extendable from C#.

[JakeSays]

@kekekeks ah i wasn't aware of the shader compiling situation. However I think SKSL is actually a good thing conceptually because it abstracts away the various different shader languages, but the compiling situation is definitely an issue.

[zezba9000]

@JakeSays Interesting. Wasn't aware ANGLE ran on WinRT. Still the ANGLE approach is a hack in my opinion... a good hack but a hack non the less as its not nearly as efficient as just targeting the native platforms rendering APIs directly though an abstraction layer designed for just that. Particularly if the platform is older. This is the difference between WINE and running stuff natively (although this offset has been greatly reduced thanks to Vulkan). From my experience native Linux apps will render faster than their Windows equivalents if the graphics abstraction layer API is designed right. Which is the approach I'm taking.

[kekekeks]

@zezba9000 BTW, Avalonia project is very much interested in platform-agnostic rendering API that won't depend on additional native libraries like Skia.

[zezba9000]

@kekekeks Awesome, well that's the kind of the it's being designed for. In fact I've had Avalonia and UNO as possible use cases in the back of my mind... as portability will be one of its strong points. I'll let you know when it can be evaluated for your project.

[MV10]

Html is hundreds of times faster than WPF

No.

[Ruedii]

The concern is porting existing programs, not creating new ones, but
rendering to HTML5 would be a good option for a cross platform intermediary
layer.

On Thu, Nov 7, 2019, 11:19 PM George Tarazi [e-mail]
wrote:

Not sure how can WPF on Linux of Mac help, Html is hundreds of times
faster than WPF, is it really worth it to spend so much money and effort to
port a technology that is so behind to other Operating Systems?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2MRVN7AJQ2EKN53EELQSTSDJA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDOVXPQ#issuecomment-551377854,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYFL2KABMRZ5ICCGZ3OVLTQSTSDJANCNFSM4GIETR6A
.

[Ruedii]

As a note, it is hard to say if HTML5 based rendering is faster when
written properly, but it does have near universal support, and other
projects have used it as a rendering layer for this reason. It is widely
used on all major platforms, even for locally rendered UI functions.

On Fri, Nov 8, 2019, 4:59 AM Jon McGuire [e-mail] wrote:

Html is hundreds of times faster than WPF

No.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2NQ7B5UKPVLN44GVBDQSUZ6PA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDPR2SA#issuecomment-551492936,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYFL2KAITLX3K4OMB3TN6TQSUZ6PANCNFSM4GIETR6A
.

[jg00dman]

WPF already works really well on wine. I am daily using Logos Bible Software which is a massive wpf application on wine. In which case, have the winehq people really solved the porting problem already?

[Ruedii]

Only partially. Basic WPF works well now, but certain functions do not.

Interacting with C/C++ modules and the use of certain embedded content can
cause issues.

Also, the ability to make application ports to Mono goes well beyond what
Wine can do. Using Mono you can make as good as native ports to almost
every platform in current use.

On Wed, Dec 4, 2019, 8:30 PM John Goodman M0RVJ [e-mail]
wrote:

WPF already works really well on wine. I am daily using Logos Bible
Software which is a massive wpf application on wine. In which case, have
the winehq people really solved the porting problem already?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2JANTCCQI5S4KTSXV3QXBKUBA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF7EX2A#issuecomment-561925096,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYFL2JPWM362KSGIQFGDCTQXBKUBANCNFSM4GIETR6A
.

[tsal]

I don't even necessarily want to target my platform, just BUILD on it. How can this be out of scope for the "core" of a "cross-platform" framework?

[MV10]

Whether HTML is faster (or fast enough, or whatever) -- the real problem with HTML and browsers isn't speed, it's that they're still inherently document oriented, which is an incredibly terrible app-development paradigm. It's only made worse by the trash-fire that is CSS.

But it's all a moot point, MS is clearly all-in with Blazor. We're still stuck with HTML + CSS (for the time being, anyway), but at least they're mostly removing JS from the equation. In a lot of ways, day-to-day Blazor development reminds me of the WPF days.

[Ruedii]

Whether HTML is faster (or fast enough, or whatever) -- the real problem
with HTML and browsers isn't speed, it's that they're still inherently
document oriented, which is an incredibly terrible app-development
paradigm. It's only made worse by the trash-fire that is CSS.

If you are writing HTML and CSS document oriented you are doing it wrong.

These are block oriented languages, not document oriented. I am always
surprised at the number if people treating HTML as if it is a tag based
word processor. While it can be used as that, such use greatly limits your
flexibility.

The same goes with the constant treating of JavaScript like it's BASIC or
non-objecr-based Python.

>

[weitzhandler]

The reason I despise HTML and CSS, is that it's non-object oriented and inextensible. I wouldn't mind defining XAML files in C#, but I love the object model of standard XAML (as opposed to Xamarin.Forms flavor).

[MV10]

If you are writing HTML and CSS document oriented you are doing it wrong.
These are block oriented languages, not document oriented.

Semantics. The browser and the markup syntax is still a document/page paradigm, period. The dev community has blown decades piling one hack on another trying to turn web-based apps into a reasonable approximation of the quality of native desktop apps we routinely produced 20 years ago.

Pointless to worry about it either way though, they just aren't going to commit resources to xplat WPF, and it looks like they won't open up the code, either. Heck I'd guess WCF server code is less complex and less-tied to Windows internals and they won't share that, either, despite the very large, very lucrative enterprise community being up in arms about it for virtually the entire time .NET Core has existed.

[JakeSays]

@GeorgeTarazi I'm not sure you understand the nature of this issue. It is not about finding an alternative, but having support for WPF on other platforms.

[JakeSays]

@Ruedii You do realize that HTML and CSS were in fact designed to be document oriented markup, don't you? That was their original, sole purpose. Their use is to this day still primarily document centric.

[handicraftsman]

We have Skia and ANGLE made by Google. Although i doubt that will be used in original WPF, some fork might eventually try switching to them, possibly in a way which breaks compatibility (i guess name change would be enough to state incompatibility). While OS API compat and ANGLE configuration might be delegated to some "plugins" which are included by the app and loaded by the fork.

[weitzhandler]

@handicraftsman according to this, the Uno Platform with their system of code generators, can choose one day to render anything Uno Platform (including wasm), using Skia-Sharp instead of using native controls.

[handicraftsman]

@weitzhandler yes, but they still didn't implement native electron-less linux support.

[handicraftsman]

Also avalonia uses skia, but without ANGLE, thus it has no alternative to directx shaders applied to elements.

[kekekeks]

@handicraftsman Actually, Avalonia has an option of using ANGLE on Windows, it's just not enabled by default. Custom shaders will be there somewhere around 0.10 or 0.11. For now we are working on a better integration with OpenGL in general:

Note how OpenGL content is seamlessly integrated into the UI, the teapot is below the sliders.

[handicraftsman]

Oh nice, sorry for misunderstanding!

[Ruedii]

CSS is object oriented. That's the cascading part.

I can't believe how many people use HTML/CSS like Latex.

JavaScript is also object oriented but so many people just use it like
QBasic instead.

On Sun, Dec 22, 2019, 3:09 AM Shimmy [e-mail] wrote:

The reason I despise HTML and CSS, is that it's non-object oriented and
inextensible. I wouldn't mind defining XAML files in C#, but I love the
object model of standard XAML (as opposed to Xamarin.Forms flavor).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/wpf/issues/48?email_source=notifications&email_token=AAYFL2PJTMSSNMXMM3SAJH3QZ4OFJA5CNFSM4GIETR6KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPKZNI#issuecomment-568241333,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYFL2NMPAYQUR5NKW22SDTQZ4OFJANCNFSM4GIETR6A
.

[ccifra]

For those that may be interested, I've created a post on my experiences running .NET Core WPF Apps on Linux with Wine. As others have mentioned, it works quite well.

A developers guide to running WPF apps on Linux with .NET Core and Wine

[handicraftsman]

@ccifra hmmm, this could be nice to support running modern WPF apps on different platforms.

[weltkante]

It would be great to be able to switch to .NET Core for Linux, keep using WPF, and have WPF applications continue to work. [...] To do this, WPF needs to be updated to compile against WineLib. In theory, this should not be too difficult.

@ccifra the render engine is still not open sourced (an update on the state of open sourcing was promised for the monthly progress post in january, no idea when it will come though) and PresentationNative_cor3.dll isn't going to be open sourced, it contains e.g. the text layout engine and is just distributed as a precompiled binary blob (I assume it contains algorithms/data which MS doesn't have the license to open source, otherwise it'd be really odd to just exclude that part). You are apparently allowed to redistribute PresentationNative_cor3.dll but you can't recompile it against WineLib.

It might be possible to replace PresentationNative_cor3.dll with a custom open source implementation by reimplementing the API used by the other WPF components, but its definitely more work than just recompiling.

[ccifra]

@weltkante that is good information. I knew the WPF team was not done moving everything to GitHub but I did not realize parts were not going to be open sourced at all. That is disappointing.

[zezba9000]

I'm sure "PresentationNative_cor3.dll" create be re-implemented if someone cared enough.

[vladd]

@zezba9000 It's likely true, but at which cost?

[Ruedii]

hose that may be interested, I've created a post on my experiences running .NET Core WPF Apps on Linux with Wine. As others have mentioned, it works quite well.

Hmm, this is a useful workaround for Linux, Mac and Android as all those platforms support Wine to a degree.

It's far from ideal, but that's another matter.

I don't know why a reasonable WPF subset isn't added to the Linux and Mac versions of .Net Core. There are some segments that might take more work, but this would be nice low hanging fruit.

As a note, another workaround is porting the remainder of the Wine-Mono framework to .Net-Core so more full .Net apps can run under .Net core on Wine.

Still, these are workarounds and less than ideal.
A partial port of the "low hanging fruit" segments of the framework would be good. I understand if some portions of it can't be implemented in .Net Core.

I wonder if borrowing some of the implementation of other unsupported .Net framework segments from Mono might help for cross platform replacement of the needed base framework for WPF.

I'm also wondering, could a selectively stripped Windows version of .Net Core 3.0 be built against WinPR (Windows Portable Runtime, a bit lighter of a Windows replacement that doesn't implement the kernel, system and memory map layers.)

Another option is could a big portion of WPF itself be rebuilt for .Net Core 2.x for Linux using WinPR for the drawing calls?

[Ruedii]

I still don't get why this is closed without any rational.

It should be left open as "triaged" i.e. we won't bother fixing it, but we acknowledge it.

Closing it is saying "Screw you, we don't even want a pull request if someone else does it."

Saying the issue isn't important to you and marking the request as "triaged" is the proper thing to do here, NOT marking it as "closed" after all it's that they won't fix it themselves, not that they won't fix it at all.

Microsoft needs to learn the Open Source process if they get anywhere in the world. Otherwise they will die in obsolescence.

If they keep this up, someone will fork .Net Core and Mono and make an alternative with a proper community, or people will just abandon WPF and any other .Net only CIL frameworks and Microsoft will end up losing control over CIL again.

[zezba9000]

@Ruedii Its closed because its not important to MS. WinUI 3.0 if anything will be more natively portable.
If a team/group cares enough about WPF specifically, they will need to fork this repo (thats pretty clear at this point).

But again WinUI 3.0 is the better long term focus as MS is even funding portability of WinUI via supporting the UNO team.

[Joebeazelman]

I took a look at UNO and wasn't impressed. It's really all hype with little substance. It's just another middleware on top of Xamarin for supporting HTML/CSS. The UNO team took the cheap and lazy route by adding an HTML/CSS backend and sprinkled a cross-platform "abstraction" layer. It's shamelessly leveraged off of what's already a part of Mono. Once you get past this thin veneer, the emperor wears no clothes. The people behind UNO, nVentive, are hoping the their target market, corporate executives, are too dumb to figure it out.

The UNO team will probably support WinUI 3.0 indirectly through Xamarin. They don't support MacOS directly. They are waiting until Mac Catalyst is released before committing any support to it. Since Catalyst is an Apple API for running iOS apps on MacOS, they hope to get Apple to do the hard work for them. For now, they recommend targeting MacOS through UNO Web running under Atom. I laughed out loud when I read it.

Their demos are crude and simplistic. The iPhone demo app was especially slow and flickered like crazy and behaved more like a web app than an ios one. UNO is just vapor with lots of marketing drivel behind it. Its maker is high dollar software consultancy hoping it will lead into larger and more lucrative consulting gigs. Microsoft is supporting this vapor job out of pure desperation. They're hoping nVentive will help them win back the enterprise development market that they blundered on.

[Ruedii]

I was thinking this might be a bet

@Ruedii Its closed because its not important to MS. WinUI 3.0 if anything will be more natively portable.
If a team/group cares enough about WPF specifically, they will need to fork this repo (thats pretty clear at this point).

Still, you don't close the bug with no explanation. You especially don't close it without marking it "triaged" first.
It's just a bad way of handling it.

Maybe the bug should be changed, or moved to be dependant on another bug such as making WPF build against .Net Standard. Honestly, .Net Standard is the way to go for making the build work cross platform. It may also need to be a limited compatibility subset. Certain underused routines, especially those regarding that require Windows-Specific low level routines should be marked as deprecated and not supported on non-Windows builds.

Honestly, if I was Microsoft's .Net team, I wouldn't even consider working on this bug until the final .Net Standard 2.0 API was finalized, as that would be my target for cross platform support. This means no messing with other CIL variant compatibility bugs.

It's fine to triage feature request bugs and leave them in limbo. Closing such bugs is just bad form, ESPECIALLY if you don't tag them as triaged first.

[TangMonk]

cross-platform need!

[wstaelens]

While most developers are now at home because of the Corona-virus, go ahead and make it fully cross-platform while you have time now! 😁

[jinyuttt]

WPF or UI library cross platform needs community promotion, Microsoft as an enterprise should not, it needs monopoly. Otherwise, it is very likely to be replaced by QT

[DaZiYuan]

Don't talk about the issue anymore, I think google flutter will achieve this, just wait with patience.

[JakeSays]

@DaZiYuan Actually flutter doesn't solve this at all - it's not a .net solution.

[DaZiYuan]

It doesn't matter what program language or platform. If something can solve cross-platform perfectly and have a big opensource community, we can consider investing it.

[lindexi]

@DaZiYuan github.com/AvaloniaUI/Avalonia

[JakeSays]

@DaZiYuan well that's just simply not true. Some will switch, but for a .net shop with millions of lines of code switching makes absolutely no sense if there's a .net solution.

@lindexi Avalonia is a long way from being production quality. It's also poorly designed.

[lindexi]

It doesn't matter what program language or platform. If something can solve cross-platform perfectly and have a big opensource community, we can consider investing it.

Now we can publish a special version if we want.

Here is my blog (Chinese): https://blog.lindexi.com/post/%E6%89%8B%E6%8A%8A%E6%89%8B%E6%95%99%E4%BD%A0%E5%A6%82%E4%BD%95%E6%9E%84%E5%BB%BA-WPF-%E5%AE%98%E6%96%B9%E5%BC%80%E6%BA%90%E6%A1%86%E6%9E%B6%E6%BA%90%E4%BB%A3%E7%A0%81.html

https://blog.lindexi.com/post/%E6%89%8B%E6%8A%8A%E6%89%8B%E6%95%99%E4%BD%A0%E6%9E%84%E5%BB%BA-WPF-%E6%A1%86%E6%9E%B6%E7%9A%84%E7%A7%81%E6%9C%89%E7%89%88%E6%9C%AC.html

[zezba9000]

@DaZiYuan Flutter is not a solution. HTML/JS tech is bloated, slow and doesn't interface with native code well. People only making basic user-space apps it might work but that tech is a nightmare for non-consumer based tools that need to interface with the OS. C# is way better suited for such tasks.

[jinyuttt]

Unfortunately, for some reasons, many projects began to enter Linux, and South Korea has been promoting Linux system, so we have to consider QT. I hope Microsoft will fully isolate the database, programming tools, development language, operating system, etc., develop independently and compete independently.

[darkdragon-001]

Microsoft has a lot of interest themselves to port their applications like Office to other operating systems (e.g. porting Power Query for Excel on Mac).

[zezba9000]

@darkdragon-001 They're more likely to just use Electron and bloated web-tech than innovate here. My guess is priority fragmentation between large groups in the company. Unless they start making more money in the Linux eco system like they do with cloud services on the client side of things its not going to happen... and I only see something like that taking place with first them making lots of money off Android/Linux mobile platforms to start with. So figures crossed their Android phones do well so they set their eyes more on non-windows platforms in the company.

[danwalmsley]

@DaZiYuan well that's just simply not true. Some will switch, but for a .net shop with millions of lines of code switching makes absolutely no sense if there's a .net solution.

@lindexi Avalonia is a long way from being production quality. It's also poorly designed.

@jakesays Please elaborate?

[weitzhandler]

They're more likely to just use Electron

That's sadly true. All their recent apps have been migrated to Electron instead of making WPF or WinUI cross-platform.

[jinyuttt]

@JakeSays Avalonia what's the problem? A quick chat?

[jinyuttt]

@weitzhandler Yes, typescript is Microsoft's solution

[jinyuttt]

I'm looking at QT and Avalonia. Avalonia, for better or worse, takes the first step. I think someone is right. We need cross platform UI library, not WPF cross platform

[weitzhandler]

Avalonia what's the problem?

It's not backed by MS.

Yes, typescript is Microsoft's solution

HTML & CSS are not. And they suck as much as JS does.

Avalonia, for better or worse, takes the first step.

To me, Uno Platform, does, because it also supports WASM, and offers most of the new WinUI Windows Community Toolkit controls.

We need cross platform UI library, not WPF cross platform

Please vote!

[handicraftsman]

@weitzhandler Uno uses electron on Linux and macOS and requires Visual Studio for windows to build its stuff. Not too good for developers who use linux as their primary OS.

[handicraftsman]

Disclaimer: this is offtopic a bit.

@zezba9000 personally I would like something like C++/WinRT and Rust/WinRT, but for new .net 5 and cross platform, then, as mentioned by @weitzhandler in his vote request, a cross-platform skia-like drawing api, window management api, input handling api, etc. All this could be used to implement a full fledged UI library like WPF. Even if not by MS. Even if not UI, but just the other apis.

What comes to drawing api, i guess we'll need shader support. WebGL's GLSL could be used as there are multiple transpilers for it, including Google's ANGLE.

Offtopic begins here.

Another thing I would find useful is official set of msbuild extensions for building c++ projects and rust projects (aka those supported by whatever/WinRT devs). This would help with providing native specific code for our .net libraries.

[weitzhandler]

@weitzhandler Uno uses electron on Linux and macOS and requires Visual Studio for windows to build its stuff. Not too good for developers who use linux as their primary OS.

Announcing Uno Platform support for Visual Studio Code

[handicraftsman]

@weitzhandler target platform is still electron.

[zezba9000]

@handicraftsman Issue with a native approach is production time when everyone in the eco system for the most part is going to use C# with the UI framework. If your goal is C/C++ QT is already designed for that. Thats just my thinking on it.

A couple months ago I did a rendering layer prototype in C# that used "SkiaSharp" / "CanvasKit - Skia + WebAssembly". In short you could write pure C# apps and run them natively in Windows, macOS, Linux, iOS, Android, WASM, etc all using Skia rendering API. I used Bridge.NET to test C# in browser but a Mono WASM target should be easy as well.

The image below shows Skia being controlled from C# in 3 different hosts running on Windows: (WPF, WinForms and WASM via Edge-Browser).

Keep in mind this is just a rendering layer prototype for the feasibility of using Skia to make a full-blown XAML like UI in C#.

[kekekeks]

Keep in mind this is just a rendering layer prototype for the feasibility of using Skia to make a full-blown XAML like UI in C#.

@zezba9000 FYI, Avalonia renders everything with SkiaSharp.

[zezba9000]

@kekekeks Yes but Avalonia doesn't have support for "CanvasKit - Skia + WebAssembly". SkiaSharp and CanvasKit APIs differ and thus you need a C# abstraction that sits above them to get web support with existing and supported ports of Skia.

My experiment was specifically about making an agnostic API that sits over Skia and thus can control SkiaSharp or invoke JS wrapper methods that control CanvasKit for web. That gets you Skia everywhere pretty easy, including Bridge.NET, JSIL, PNACL or WASM via Mono which Avalonia doesn't support.

It was framework portability investigation If that makes sense.

[kekekeks]

"CanvasKit - Skia + WebAssembly"

I don't see why it can't be implemented. Avalonia only needs an SkCanvas instance. We even have a backend working on top of /dev/fb0 on Linux.

It is possible to run Avalonia on WASM, we know it because my little experiment on top of Blazor and SVG-based rendering backend from a year ago runs on wasm (even if said experiment is agonizingly slow due to, well, running on top of blazor and rebuilding the entire SVG on every frame) .

We are currently not spending any resources on WASM platform only because of the poor performance and tooling support for said platform and the lack of the canvaskit support in upstream SkiaSharp. It takes quite a bit of time to just get a dependency-less hello-world application. So we are currently spending our limited manpower on tasks that actually benefit our users and WASM support is planned right after proper mobile backends (somewhere in 2021, I guess).

[zezba9000]

We are currently not spending any resources on WASM platform only because of the poor performance

-- Its not slow in Bridge.NET and Mono is pretty fast on the WASM platform now. It was also super fast on PNACL in the day.

canvaskit support in upstream SkiaSharp.

-- You don't need SkiaSharp to support CanvasKit as I showed in my example. You only need to target CanvasKit directly in your rendering abstraction framework by creating agnostic JS feature methods (that match agnostic C# SkiaSharp feature methods) that in turn get invoked from a C# based runtime (which can be anything).

It takes quite a bit of time to just get a dependency-less hello-world application.

-- My experiment prints "Hello World!" is a spooky font and it took me _less than a day_ to make. All being controlled from C#.

I know Avalonia is a bigger project than my experiment but with the right foundation in terms of agnostic rendering layer this becomes a non-issue for most things.

[kekekeks]

Bridge.NET lacks WeakReference support, which is crucial for bindings to work. That's why we can't use it as a target platform unfortunately.

Note, that Avalonia's rendering API is renderer agnostic. We have support for Direct2D rendering without Skia to make sure that our rendering code is portable.

The drawing context abstraction layer looks like this: https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Visuals/Platform/IDrawingContextImpl.cs (CreateLayer and Custom aren't strictly required).

If you can implement it on top of some platform, then Avalonia can run on that platform.

[zezba9000]

Avalonia only needs an SkCanvas instance

-- Keep in mind SkCanvas in CanvasKit and other APIs are not 100% matching to SkiaSharp's implementation of them but the features are there from what I could tell.

Bridge.NET lacks WeakReference support

-- That makes sense as the JS runtime's GC doesn't support that. Although I don't know why you need this for binding. That object is slow.

The drawing context abstraction layer looks like this:

-- Then using the strategy I used for CanvasKit, it should be possible to do it in Avalonia + Mono AOT runtime.

Anyway good luck!

[handicraftsman]

@zezba9000 Ugh, unlike XAML-based frameworks, Qt is either imperative (while XAML is declarative), or if its QtQuick, it lacks most controls or doesn't implement them as good as XAML does. And also QtQuick isn't that popular in open source world, unlike XAML. There are Kirigami and MAUI, but uh, they're ugly and are complete style sets, not widget set standard like XAML.

[jinyuttt]

Unfortunately, without Microsoft's standard, other software suppliers will not provide .Net development interfaces, such as GIS, so Microsoft has to provide a set of cross platform desktop development library, which can not be WPF

[wstaelens]

again, we need something fully microsoft supported (support, vs integration, lifetime, etc...), xaml, and getting rid of javascript.

We are WPF/Winforms devs (C#, SDKs, XAML, visual studio 2019,..), not webdevs (javascript, vscode, scripts, 20 different browsers,...)

Still missing Silverlight. Now heading towards Blazor but would love to see XAML in there.

[JakeSays]

@wstaelens I don't care if it's microsoft supported - I just care that it's full featured and reliable.

[wstaelens]

@wstaelens I don't care if it's microsoft supported - I just care that it's full featured and reliable.

when doing business, supporting many companies, you want products that have full support in case anything goes wrong. Also a support timeline/fade out is a requirement. You can't go to an adventure in enterprise-land.

[JakeSays]

So you wouldn't use a solution provided by a company other than microsoft?

[wstaelens]

So you wouldn't use a solution provided by a company other than microsoft?

not saying that but I've seen many great projects that suddenlty have no community support anymore or that lacks behind e.g. when new OS/service pack/upgrade/.net version comes in play.

I feel great with companies like DevExpress, they have also great (enterprise) support, strategy like microsoft etc...

[HubKing]

I don't know about others but most of the time, I use only a limited portion of the vast WPF. Wasn't Microsoft's Silverlight sort of like a subset of WPF and worked on other platforms than Windows? So, even if porting the whole WPF to other platforms would be a daunting, expensive work, can't Microsoft make something like a new subset version of WPF that is cross-platform with a relatively less work? It does not have to be compatible with WPF, but just similar so that programmers can re-use their existing knowledge.

Java has at least three cross-platform GUI frameworks, AWT, Swing, and JavaFX. It makes little sense that .NET cannot provide even one basic cross-platform GUI framework. Isn't Microsoft a big, rich cooperation?

[sunliusi]

GUI is the biggest advantage of .net, It would be unwise to abandon cross-platform gui

[jinyuttt]

Did Microsoft find that QT update is fast, and more and more QT is used? Why? Will the desktop be defeated by QT? Is there a case of mobile version?

[JakeSays]

@jinyuttt not sure what you're asking, and not sure how Qt could defeat the desktop, as the two concepts are orthogonal.

@handicraftsman your assessment of qt declarative is a bit off. The rendering quality is superb, at least as good as wpf. Furthermore xaml doesn't implement anything - it's just a markup language, just like QML. If you want to do a comparison compare Qt's control set with wpf's control set and ignore the markup, as both wpf and qt declarative can be used imperatively without any sort of markup.

[jg00dman]

wine reports inclusion of wpf in mono from version 5.7

[madewokherd]

wine reports inclusion of wpf in mono from version 5.7

That's only meaningful inside Wine, and it'll likely be some time before it's complete enough for real applications to work. .NET Core with WPF has been reported to work in Wine, and that's probably a better solution for any application developers wanting to target Mac or Linux using WPF, but not a replacement for a proper cross-platform implementation.

[AZ-X]

This workflow uses actions that are not certified by GitHub.
They are provided by a third-party and are governed by separate terms of service, privacy policy, and support documentation. This workflow will build, test and package a WPF desktop application
built on .NET Core.

That's why I join this endless conversation of the issue

[walterlv]

Microsoft Build 2020 news:

MAUI is the one that will hold the hope of cross-platform for the XAML-based UI Framework. It will be available with .NET 6 in November of 2021.

https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/

[weitzhandler]

From what I gathered, MAUI is Xamarin.Forms with some touch ups. 😢
Not MS XAML, not desktop friendly, no web, renderers, not enough desktop controls, only native look and feel, etc. etc.

[jinyuttt]

QT will beat WPF

[JensNordenbro]

@jinyutt, QT is totally unusable for many since either you purchase a comercial license or you will eventually have to license your application as GPL since many useful components(more and more) are adopting GPL.
If you are fine with that & c++ I guess it is Great but then again it is not a first class C# citizen which is the aim of the discussion here. Why not Flutter or HTML5 instead? (retorical)

[juanfranblanco]

@wadepickett I guess as an entry point MAUI can and will bring lots of benefits, specially anyone starting with .Net and for extended scenarios or different use cases Uno and / or Avalonia will be necessary the same as now. If MVU becomes the new way that people chose to start working with MAUI, the Xaml discussion might shift into specific capabilities and how to achieve those in those other platforms.

[popcatalin81]

MAUI looks really cool for phones & tablets, simple to medium complexity apps.

However we need WPF cross platform for full fledged desktop applications with Complex UI. And by complex I mean Visual Studio complex, or Photoshop complex or 3D Studio Max complex.

[jinyuttt]

Avalonia is suitable for desktop, but it's troublesome without full support of VS

[QuAzI]

Avalonia & Xamarin look most suitable. But right now Xamarin can't be used in Linux. I can't build even simple project in Rider.
It would be nice to have one solution for all platforms (include mobile)

[jinyuttt]

Recently, I have learned about Avalonia. There are many components, controls and projects built by Avalonia. It's on a scale

[JensNordenbro]

I tried out Avalonia on a Raspberry PI 3; capable but super slow app startup although I used the version that included some optimizations on that part :(

Also tried Xamarin GTK-sharp2 on the same. Much faster startup but looked really old and was unfortunately hard to get started with; almost no one to support me and bugs everywhere.

I guess both will improve but today neither feels rock solid.

I actually was quite intrigued with a WPF starting on Wine; maybe some fork of a subset of winelib taking the place of Win32 would be feasible.
Or maybe just a fork of WPF instead!

[kekekeks]

@JensNordenbro have you tried using R2R? Avalonia has way more managed code than GTK# (since GTK itself is native code), so a huge part of the app startup is spent on JITting the application.

Also try playing around with OpenGL acceleration options in raspberry config and setting UseEGL in X11PlatformOptions for Avalonia. Reportedly some of the configurations provide way better FPS than default one that might be falling back to software rendering.

[jinyuttt]

@JensNordenbro I suggest we go to Avalonia to discuss this issue directly

[wstaelens]

Instead of discussing which framework will allow you to create French fries (actually Belgian fries!) in 2030. Why not let us open up many many many tickets on the MAUI github page ( https://github.com/dotnet/maui ) and let the community speak that we need our WPF/XAML shit in there. 😈 Microsoft has to listen to their users and customers, right? 😉

If Microsoft forces us again with something that can't handle complex applications, well we'd better help them with suggestions. Not want to end up with investing time and money again in stuff that will die 2 years later (Windows Phone, Windows RT, Silverlight, UWP, etc..)

[angel6708]

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

BAD 决定 証書に

[QuAzI]

Looks like progress had stuck before dotnet core became really crossplatform.
Java, JS, Qt... even Delphi... available almost everywhere.
And only with dotnet we should think twice what should we choose next time, because dotnet isn't crossplatform, xamarin isn't crossplatform, mono is ugly

[jinyuttt]

At present, Microsoft will not do this. It's better to make suggestions and contributions to Avalonia. Let's make Avalonia strong, at least without waiting.

[jesusdesantos]

If you need robust multi-platform XAML/WPF implementation we also have NoesisGUI

https://www.noesisengine.com/

[JakeSays]

@jesusdesantos If you can't respect my time enough to put pricing information on your site then I am much less likely to consider your product.

And why such a useless indie offering? No release binaries? Seriously? Provide a fully functional, useful, reasonably priced indie product, and charge for it. It is the defacto industry standard, after all. If you're going to use github as a free advertising platform then at least have the decency to offer products that are not indie hostile.

Your product is tailored to the gaming market, not general purpose application design. While it may be useful for such things your site doesn't reflect it.

Overall not impressed.

[jesusdesantos]

@JakeSays Although I understand the appealing of a FREE solution, you already have examples of that, like Avalonia, maintained by the community that are far from ideal to implement robust and professional solutions.

Our solution has been used in thousands of products (there is a list of clients at our website) and is compatible with almost all available platforms in the market right now. We also offer support and direct communication with our staff, with guaranteed response time.

We would love to give this for free, but we have a dedicated team working every day exclusively on NoesisGUI, and this costs money.

Honestly, the first TIER of the Indie license is a gift in comparison with what you get in other alternatives.

Our product is not only for games, we have many customers doing applications. We are focused on the most demanding platform (games), if you are able to do games with NoesisGUI (with constraints such as rendering in under 1 millisecond) then doing a business app is trivial.

[weltkante]

Honestly, the first TIER of the Indie license is a gift in comparison with what you get in other alternatives.

@jesusdesantos maybe if you know what it does, but for a first time visitor looking for a solution it looks totally intransparent. Like @JakeSays said, no price and no _explanation_ what the differences are, just random keywords used in nonstandard ways. The term "release" is commonly associated with releasing your product to an audience so to a common visitor your "indie tier" looks like an unlimited trial you can't use for production. Giving out an unlimited trial for free is not something you should praise yourself on.

If you want to be credible, be transparent and not a black box that could just as well be an opportunistic project that just promises a solution and doesn't have the experience or resources to back it up long-term (not claiming you are, but the site doesn't make it distinguishable). Achieving that doesn't require being open source, having transparent pricing, actual explanations of feature differences, a history of blog posts etc. go a long way in making a project credible.

Yes you can get a reputation without doing that, but don't complain if people bounce off of you like above.

[jesusdesantos]

This is my last comment about it, because I don't want to use Github for advertising.

Is there anything more transparent than directly providing a download of our product that you can try, evaluate without time restriction and feature unlimited?

While most people stay philosophizing and rambling about the ideal WPF world, we, Noesis, dedicated 6 years of our life to create a product that is source compatible with WPF, much faster and multi-platform (windows, macos, linux, ios, adroid, raspberry, nintendo, playstation, xbox, webgl). Because we firmly believe UWP fiasco should have never happened and because we love WPF.

It is your choice to consider our work scam.

[weltkante]

@jesusdesantos none of your downloads work without registration, so no you don't provide a direct download. Aynways, there were multiple points mentioned that are intransparent, feel free to adress them or don't, but as-is I won't bother looking deeper into using your product for non-game purposes.

For what its worth, intransparent pricing structures are often made to extract as much money as possible from a customer. While its valid to have price "up for negotiation" you can be transparent about that as well. I know its common for game frameworks (because game frameworks are hard to make and if you aren't a mass-market product its your best option) but having "price up for negotiation" on a UI framework for non-game applications that just want to be portable is questionable at least.

Maybe thats an indication that your framework _isn't_ so well suited for non-game apps as you thought after all. The market for UI frameworks for apps is very different from games.

And no you don't need to respond to that, I'm just leaving this here as explanation. As far as the wording of my previous post was concerned comparing with a 'scam' site may have been a bit hard but in lack of a better wording -not a native speaker- it was the most appropriate I could find and I had put it in quotes to indicate that it wasn't an exact match of what I meant and wasn't to be taken literal like you did. I edited it anyways to be less offensive, but mind you, I don't want to be entirely non-offensive, your project site does offend me as a potential customer.

[JakeSays]

@jesusdesantos I did not ask for a free version. I asked for a reasonably priced fully functional indie version. Not providing release binaries is NOT fully functional, and not being able to use it for development is just silly. Having revenue caps for indie versions is fine - I have no problem with that. But a broken indie version (yes, no release binaries is broken) isn't a gift by any means.

Also forcing me to talk to you just to get pricing information is really a pain in the ass as it makes decision making much more difficult. It truly feels like you're hiding something, which is contrary to transparency.

[JakeSays]

@QuAzI Just how exactly is dotnet not cross platform? It runs perfectly fine on linux/windows/macos. Do you want it on a gameboy or something?

[zezba9000]

@JakeSays > "Do you want it on a gameboy or something"
-- Me: Yes! https://github.com/reignstudios/CS2X

Currently doing some Unity3D stuff ATM but that project will allow C# to run on GameBoy at some point when I get back to it.

And you thought your question was rhetorical ;)

[JakeSays]

@zezba9000 LOL indeed I did.

[QuAzI]

@JakeSays

@QuAzI Just how exactly is dotnet not cross platform? It runs perfectly fine on linux/windows/macos. Do you want it on a gameboy or something?

You can't create GUI application from standard template in MSVS on Windows and then build and run it on Linux/Android/FreeBSD.
Portability is too limited because of UI restrictions and "do not intend to accept contributions" policy

[JakeSays]

@QuAzI Ok that's WPF, not dotnet. dotnet (coreclr+corefx) is highly portable. Also being able to use vs to target *nix isn't a function of dotnet's portability as vs is a separate product entirely.

[QuAzI]

@JakeSays
WPF is part of .NET Framework (since v.3). .NET Core is next .NET Framework (v.5). WPF is not portable >> .NET Core is not fully portable. And policy still prevents it from being portable. Just a fact.

[minecraftchest1]

Just because the policy says no, doesn't mean you can't fork it and say yes.

[QuAzI]

No means No. Nobody can build your custom software sources by default means nobody will use it.

[jinyuttt]

Avalonia is basically complete, so I decided to enable it and not pay attention to Microsoft for the time being

[JakeSays]

@QuAzI Just because WPF installs on windows doesn't automatically make it a part of .net core. Out of the three major (and many minor) platforms, windows is the only one where wpf exists. .net core is completely portable.

[wstaelens]

WPF is actually the 'successor' of winforms.
We still need fullblown desktop apps and here is where wpf comes into play and makes live easy for us with xaml etc..
With the universal apps, uwp apps, portable .net core standard or whatever they call it these days (what a mess!) these are just fine for weather apps or todo lists.

Just make wpf cross platform and make it fully available. If it is a lot of work to do, well start doing it instead of telling the community it is much work.
All I see is that Microsoft is launching products and tools and dropping support after some months or years. Silverlight, XPS, Windows Phone, etc...

Many small companies invest in new development and have to make choices from the beginning. Choosing for WPF is one of them. Development can take up to 2 or 3 years in many cases.
Microsoft should think about this and all these companies who have been there for Microsoft since the very beginning of .NET.
Now a bunch of open source mac linux airbook ubuntu diehards at Microsoft who have not been familiar with the beginning of .NET and its ecosystem are actually bringing it down with their process.

Don't know how to express all of this in English (not my native language) but there have been many frustrations over the last years with the vision of Microsoft.
It all came worse with the Windows Phone dude responsible for the phone but not using or believing in his own product.

Now just make WPF cross-platform.

[kekekeks]

With the universal apps, uwp apps, portable .net core standard or whatever they call it these days (what a mess!) these are just fine for weather apps or todo lists.

This app is built with Avalonia (clickable):

Is that "fullblown desktop" enough for your needs?

[JakeSays]

@wstaelens I disagree with your claim that .net core is being "brought down". This is not the case at all - its utility is being expanded much further than windows. I fail to see how that is a bad thing.

[JakeSays]

@kekekeks That's not bad at all! I'm impressed.

[minecraftchest1]

I think it seems a lot harder to port then it actually is. Probably what really makes it hard is the fact that it used just directx. That means that we can't just turn all of the directx calls into opengl/vulkan calls. We also have to put gtk/gtk+ calls in to create the windows and stuff.
Probably the best thing to do to port it is use and existing open source shin (such as ReactX, part of Reactos), change the win32 calls into gtk/gtk+ calls, and reference that instead of DirectX calls.
Much of the hard part is done for us already.

Sent from my T-Mobile 4G LTE Device

---

From: Big Jake [e-mail]
Sent: Thursday, July 16, 2020 6:29:04 AM
To: dotnet/wpf [e-mail]
Cc: minecraftchest1 [e-mail]; Comment [e-mail]
Subject: Re: [dotnet/wpf] Make WPF cross-platform (MacOS and Linux support) (#48)

@kekekekshttps://github.com/kekekeks That's not bad at all! I'm impressed.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/dotnet/wpf/issues/48#issuecomment-659350402, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIAII4ABJ5J5VRQ3VBGMBTR33QABANCNFSM4GIETR6A.

[darkdragon-001]

@minecraftchest1 Probably easier is starting from WineD3D or DXVK (used by Steam's Proton). Step by step the original WPF code could be migrated to be based on a cross-platform library (e.g. Skia).

[svick]

@wstaelens

In case you missed it, the Microsoft plan for cross-platform desktop GUI is MAUI. They went with this approach, because WPF is inherently a Windows technology (and not just in the implementation), while MAUI is built to be cross-platform. It will have "xaml etc.". Whether it will be suitable for more than just weather apps and todo lists, you can judge for yourself when it comes out.

Many small companies invest in new development and have to make choices from the beginning. Choosing for WPF is one of them. Development can take up to 2 or 3 years in many cases.
Microsoft should think about this and all these companies who have been there for Microsoft since the very beginning of .NET.

They are thinking about that, that's why they ported WPF to .Net Core and made it open source. WPF is not dead (I hope), it's just stuck on Windows.

[JakeSays]

@svick MAUI is nothing but a repackaging of xamarin forms, which is basically a GUI framework abstraction framework instead of an actual GUI framework. In other words, it uses the native UI framework of each platform, which isn't something I would want.

And WPF isn't as windows centered as they would want us to believe.

[JakeSays]

@minecraftchest1 I would rather see the native bits ported to skia than reactx, especially since reactos's license terms are horrible.

[JakeSays]

@darkdragon-001 hmm. dxvk looks interesting.

[zezba9000]

@svick MAUI (aka Xamarian.Forms [much better name]) only solves an issue for a small set of ppl.
Its about the most unproductive way to write an app to have each platform render your UI in a different way for each one.

If there was a good way to fund an Open Source XAML UI framework It would be temping to make one.

[popcatalin81]

They went with this approach, because WPF is inherently a Windows technology (and not just in the implementation), while MAUI is built to be cross-platform.

@svick

WPF uses abstraction layer for rendering. WPF also hides the windowsisms like handles and window messages in abstractions. WPF was originally architected to be platform independent and idenepend of windows idioms at API level.

The only issue I see is that it's a Desktop technology and not a mobile centered one, and Microsoft doesn't seem to wan to invest cross platform technologies that are not mobile centric.

[wstaelens]

They went with this approach, because WPF is inherently a Windows technology (and not just in the implementation), while MAUI is built to be cross-platform.

...
The only issue I see is that it's a Desktop technology and not a mobile centered one, and Microsoft doesn't seem to wan to invest cross platform technologies that are not mobile centric.

yes, sad story, because most mobile devices are coming as powerful as 'slow' desktop devices. Not everything should be forced to being mobile or limited to mobile/portability.
I've seen some great comments here. Hope some from Microsoft pick it up...

[JakeSays]

@zezba9000 I wonder if a kickstarter would work.

[zezba9000]

@JakeSays Kickstarter might work to "kick-start" the project for a short period of time but longer term cash flow would be needed.
Maybe by offering paid support, subscription donators or selling special closed-source controls. Eitherway you need to be able to support the project as the platforms it runs on evolve and change.

[rufw91]

After reading this discussion for the better part of my morning, i feel i need to add my $0.02. Firstly, this is an open-source project so we, the community should have the majority vote(and also electoral), secondly, if we can do it why not just allow it, who is getting hurt?, Finally, someone hold my beer while i clap for @Ran-QUAN

[svick]

@rufw91

this is an open-source project so we, the community should have the majority vote(and also electoral)

Open source does not imply democracy. The maintainer always has the last word, whether that's a corporation, BDFL, or someone else. If the community disagrees with the maintainer, they have the option of forking the project. (Though that is always a risky move that requires a lot of effort.)

if we can do it why not just allow it, who is getting hurt?

From MS point of view, I think doing this would hurt the quality of the product (i.e. it would introduce bugs). They seem to be unwilling to dedicate much resources to WPF (see the roadmap, where they are talking about merging just 1 or 2 community PRs per month), which means allowing work on porting WPF would require having little to no oversight from MS, which would inevitably lead to introducing bugs. Given these constraints, I think disallowing the port is a reasonable approach.

[wstaelens]

Bugs will be fixed, when they see many developers will use it they'll jump back on to it. Don't worry about this.

[Ruedii]

Also there is no reason the large milestones can't be made in a branch and
can't be pulled over in large pulls.

Here are the steps needed:

1. Isolate DirectX specific code for all but shaders in Arch/WinNT
   subfolder.
2. Further isolate context management code.
3. Implement replacement context management code.
4. Implement remaining DirectX calls through a portable alternative
   implementation library.