Thanks, @jesusdesantos, looks like a great thing and I can’t wait until I get the chance to get this implementation of WPF running on Windows, OSX, Linux, iOS, Android, Windows Phone, Windows Store, optimized for realtime!
From the sticky post at the top of the forum:
- Please no product endorsements: This forum is meant for discussions around Open Source Software. Please refrain from promoting your products here that are not OSS as they may be treated as spam by our community.
Beyond that, this thread is about an open-source version of WPF, whether using the existing as a base, or writing a new one…
It’s probably good to know about such a library, but I’m not sure this is the best place to discuss your product…
I run ILSpy on wine. Result - possible, but buggy, needs .NET 32 bit. So if there is use case for WPF on Linux it may development tools. Opensourced managed parts of WPF may reduce hoops needed to install and debug WPF on Linux. Wine uses Mono by default to run .NET executables, need to reinstall with .NET to have WPF, so if WPF managed assemblies be with Mono, there one point less to tackle running WPF. Having native part of WPF to work well at is story for Wine.
The main reason for this was WinForms GDI text rendering. When ClearType is disabled on Windows 7/XP systems WPF apps have blurry text. Native WinForm apps (with ClearType disabled) text appears crisp and apps respect non-aliased text rendering of the underlying rendering engine. So, any app using Eto.WinForms works and renders like any other native WinForms app.
+1 for Eto.
@HarikrishnaMenon this is very nice ! Do you have any news ? any results after the investigation ?
You could port your your project to Silverlight and deploy it as an OOB.
Silverlight requires your users to install the plug-in on their machine (takes seconds), but is a doomed/dead technology that MS has loudly abandoned.
Google has dropped SL support for Chrome since version 39. Read the Silverlight article on Wikipedia, especially the first few sections, so bear in mind not to put to much effor if you do decide to port it to SL.
It also depends in the leverage of the WPF functionality your project takes. Silverlight is a subset, more correctly a tiny subset of the whole WPF feature-set.
Anyway that’s still your best bet, especially if your app has already been developed, and especially based on my understanding that that you want to develop the ‘client’ app for those platforms.
And besides, I’m sure you might find a lot of interest in my post: .NET Core for Web.
Consider Nevron Open Vision - it is a .NET UI layer with most of the WPF functionality (like advanced property dependencies, inheritance, CSS styling etc) that works on Windows and MAC. I work for this company and we also have plans to make it running on Linux (it already runs on Mono Mac)…
Whilst I am all for something like XAML as a part of the .NET Core; I think that it would be extremely useful if there were some sort of general purpose binding support in .NET Core so that it’s easier to reuse application logic with different “view” controls.
It would be interesting to hear other peoples thoughts on this; I have opened a feature request issue ticket here:
I would also rather like to see a general purpose XAML template parser which makes it possible to parse and build a UI by implementing some sort of IUIBuilder interface where bindings could be wired into the general purpose binding mecanism.
In order for it to be possible to reuse existing application logic I believe that it would be good to stick to the
INotifyPropertyChanging interfaces; although there seems to be some opposition to this in my issue ticket.
Just in case anyone here is stuck on this wondering what other people are doing, I just wanted to follow up with the solution I am going with and my personal recommendation.
The general recommendation is to move away from XAML and consider it an obsolete technology. Existing apps should continue to work and have support for a while longer but you should not create new apps with XAML based technology and you should consider replacing your application with a different technology if feasible.
There are a lot of replacement technologies out there, the one that is probably the most comparable at this point and the one I recommend people switch to is Electron: http://electron.atom.io/
Good luck everyone, and R.I.P. XAML
Look at what the “Spotify” guys did. They built a c++ client, that is just a shell for chromium engine. The whole UI is (propably) HTML 5 / JS / CSS. I think, the link to the electron/atom is nearly the same concept, that Spotify did.
And always remember this: The normal user does not care, what technology is behind something. The normal user just wants a fast, beautiful and crash-free UI, he can play with. No matter if WPF or JS/HTML.
From a developers point of view, XMAL/WPF with all it’s possibilites to build decoupled applications, is the heaven.
And I think WPF will be here for a long time. Just because every bigger enterprise in the world (!!!) is de facto using Windows clients for it’s IT infrastructure. Show me one bigger organization that relies on iOS or Linux. You wouldn’t even be able to read any Microsoft Office Files without the known problems.
So if you live in the LOB world, WPF will stay. If you live in the consumer/tablet/phone world, cross platform matters.
First off, I just want to say what an INCREDIBLE and informative thread this is! Wow. I just read all 70 posts and I am seriously overloaded with all the information contained in this thread.
@justinmchase - I appreciate you moving on, but I wouldn’t say there’s a general recommendation to abandon Xaml. Xaml is alive and well in every major MSFT group except for ASP.NET (and this should be fixed, LOL). Xaml is also very much alive in Xamarin as well.
However, I do feel your pain when it comes to cross-platform/web-based Xaml.
In any case, I would definitely say with 70 (really amazing) posts on this topic, there is definitely a need for a consistent, ubiquitous cross-platform .NET client application model that works not only in compiled (native) runtimes, but also transpiles into HTML5-compliant artifacts and works on websites as well. Something that hits EVERYTHING. And no, it’s not impossible. It will just take some time.
Having a unified, official cross-platform library for Xaml serialization would be awesome, too.
Perspex / OmniXaml / Noesis have all got my attention. I was unaware of any of these until today. EmptyKeys is also cool, too.
Anyways, great thread. Really enjoyed the read.
This is something that can happen in .NET solutions but not web solutions.
Using nodejs on the server and electron for the client, you can easily create packages that can be run on the client and the server.
Psst… you’re in a .NET forum, not a node.js forum.
Hi guys, just to let you know that Perspex (a cross platform .NET UI framework inspired by WPF) has just released alpha 2: http://grokys.github.io/perspex/perspex-alpha2/
Hopefully this isn’t spam; some of the people who discovered it on this thread asked me to post it here!
From @Clockwork_Muse’s post above it sounds like you can discuss projects that are open source. I don’t consider this spam and think it’s quite relevant. We need active answers to this problem now, not a bunch of conjecture and musings that lead/delay us to wait a few more years until someone finally decides to get their act together.
Agreed with @DragonSpark FWIW - your post is definitely not spam @grokys. The community might take a different view if it was a closed source solution or vaporware but what you are doing is incredibly relevant to this thread and so welcome (and congrats on the Alpha 2 release)
I think what makes something spam is when it’s a whole “ad” for the framework, not a quick note about it
FWIW, I have published an article that references this (incredible, really) thread, while exploring the problem that .NET client application developers face today in lieu of a ubiquitous client application development model offering from Microsoft. Sadly, as @justinmchase has illustrated, the logical choice is to move away from MSFT-based solutions to HTML5/JS web solutions to better integrate and utilize code between client and server.
If interested, the reference can be found here:
Although this sounds damning, the article is part of a series with the goal of procuring votes towards creating a ubiquitous .NET client application development model that saves developers (and organizations) from having to make this difficult (and expensive) choice:
Microsoft can`t open source WPF, unless the Windows system completely free.