Will the windows only library get open sourced too?


#1

I’m wondering if libraries that never made it to mono will end up available cross Platform and / or get open sourced in the process (like WPF for example).

I’d love to be able to use WPF on any platform on which .net can be ported.


#2

So why didn’t Microsoft make the client-side open source?

I guess that it is because those code bases (WPF, WinForms etc) are quite old and not written with cross-plattform in mind - and they also probably make use of proprietary code from vendors other than Microsoft.

It is most likely better building new frameworks, adapted for the modern modular cross-platform approach of .NET, rather than asking Microsoft to release them as open source.

We should make a “.NET Presentation Foundation” for desktop clients.


#3

Yeah, WinForms on Unix systems is not fun.


#4

My understanding is that the open sourcing efforts do not include the client libraries at this point.

In Windows.Forms case, even if it is open sourced, you would still need a Win32 emulation layer, as Windows.Forms is really a managed API on top of Win32. Mono provided a partial emulation of a Win32 stack to allow some Windows.Forms code to run.

If the code was open sourced, it would at best provide a good source of material to replace some parts of Mono’s Managed.Windows.Forms stack. But you would not be able to run it directly, or port it without a significant effort.

If WPF was open sourced, you would also need some Win32 emulation layer and other Windows-provided APIs that are just not exposed.

Both would provide starting points for a fairly long porting process.


#5

@migueldeicaza

Seeing that you guys at Xamarin have achieved the awesomeness that is Xamarin.Forms, which does support the 2 particular aspects of WPF we WPF-first developers care about (XAML and MVVM), what chances are there to implement a Xamarin.Forms.Linux which transforms XF elements into GTK# and Xamarin.Forms.Mac which transforms to native OSX UIs? maybe it won’t make sense for Xamarin to do that from a business perspective, but I’m pretty sure the community would be really enthusiastic and engaged if there was such a project.

If you could create the core layers, I’m pretty sure the community would welcome such a thing, even if you don’t take the time to create all the individual controls, which can then be created by us =).

This way, we’d have a really cross-platform XAML-based MVVM-capable UI framework that doesn’t really depend on Microsoft eventually open sourcing parts of WPF, or the Mono Team reimplementing such a huge framework from scratch.

BTW, pleasure to talk to you.


#6

Xamarin.Forms is really aimed at mobile/tablet form factors, so it is not really a general purpose API to use on desktop computers.

But I do have good news for you, we do have a toolkit that does the same thing as Xamarin.Forms, but focused on the desktop. It is called Xwt and currently has WPF, Cocoa and Gtk# backends:

Miguel


#7

@migueldeicaza

Hey, thanks for your response.

From what I’m reading in the Xwt Github page, there’s no XAML or MVVM support.

Do you believe Xwt is a suitable starting point for the community to create a XAML-based, MVVM-capable cross platform UI framework? we would have to add XAML and DataBinding/DataTemplating (which enable MVVM) into it.

Since XAML is really XML, and the existing XAML infrastructure is platform-agnostic (in the sense that it creates an object graph from a XAML document, regardless of what the actual types of the XAML elements) I think it’d be a much smaller task than trying to figure out how to implement a WPF-like UI framework from scratch.


#8

Hello,

It could. Xamarin.Forms was actually inspired by Xwt, and we only later added MVVM/XAML to it.

There are various MVVM frameworks that you could get bits from to get what you want.

That said, the Xwt approach is similar to Xamarin.Forms which is to expose a single API, and that is mapped to some underlying control. For example, you create a “Xwt.Entry” and that depending on the backend creates a WPF text entry, a Gtk Entry or a Cocoa NSTextView.

It is nice in that you write the code once, and it runs everywhere.

What we found with Xamarin Studio is that this works, but our users want native experiences. This means that even if our “Entry” was native, we could not really do or express everything that is possible on each platform with a particular entry (color, font, text attribute ranges, handling non-contiguous selections, accessibility and so on).

We wanted to be able to leverage everything a native platform did.

So new Xamarin Studios are moving away from Xwt, and we are moving into an MVVM world, where bits of code are 100% shared, but we write three independent UIs for everything.


#9

@migueldeicaza

I’m glad to hear that. I understand that a platform-agnostic UI framework can never deliver ALL the possibilities available on each of the target platforms, otherwise you would have to start leaking implementation details of each platform into the “upper layers” of the framework, which doesn’t sound very good.

@ronan_thibaudau

To answer the overarching question of your post, I don’t think WPF is going to be open sourced, and even if it is, it’s going to require a tremendous amount of work in order to decouple it from Windows-specific APIs such as DirectX and Win32 and adapt it to be cross-platform, OR as Miguel stated, to emulate these Windows-specific layers in other platforms in order to provide compatibility.

At this point, I don’t think it makes sense from a business perspective for Xamarin (nor Microsoft) to do that, which means such a huge task is left on the hands of the community.

As per Miguel’s comments, it’d be a more realistic course of action to build upon Xwt, which is an existing Cross Platform UI Framework, which at the moment does not offer any sort of MVVM or XAML capabilities, but serves as a viable starting point. OR take the MVVM route in the form of platform-agnostic ViewModels and then creating platform-specific UIs.


#10

Hi guys,
Having WPF/XAML/MVVM on other platforms was always my dream too. So I created XAML based UI myself.

Empty Keys UI is PCL UI Library using MonoGame or SunBurn for render. As I’m mainly game developer It’s main purpose is for creating game UI, but … You could use it for simple applications on Linux/OSX. I know, it’s not WPF and it does not support all the features. :slight_smile:

Library is not open source, but it’s for free (MIT license). It comes with UI Generator from XAML to C#, which is open source on GitHub.


#11

I still would definately like wpf open sourced as a whole, it doesn’t “look” at all like it is as dependent on win32 as winform is and it would be great to port it and have full compatibility with all of .net (making a fallback software render mode that could be a portable Library maybe?) as well as an OpenGL backend for non directx platforms.

Personally i could see myself working on porting it to use unity for rendering and having it target all unity supported OS directly for example. If someone could make noesis GUI from scratch i’m sure it would be substantially easier to do with the actual wpf stack, and it would mean the full feature set not just “some xaml + C# support”.


#12

Actually WPF is pretty much build on top of WIN32. It’s even using classic HWND for main window, the same stuff like WinForms. You can see the sources on http://referencesource.microsoft.com to see it yourself.


#13

Of course it is, but most of it is likely rather independant, Windows is a good non-example, they’re OS specific concepts (on phones you wouldn’t even use Windows as containers). But what gets rendered Inside doesn’t feel very “win32ish”. Having access to shaders, two way UI databinding with notifications, triggers, transformations etc, none of that is win32, it may be built “on top of”, but the hard part is what’s built on top, not what supports it, so open sourcing wpf would be great, as if i wanted to redo wpf on another Platform what would worry me is well, the WPF part, not the what’s bellow it part. It would also mean we could reuse things built on top of wpf on other platforms (like Telerik components etc)


#14

Even if Windows only, it would be great if WPF was open-sourced:

  • ability to trace and understand behaviors/internals better
  • easily find and fix bugs
  • add new features
  • ports to other platforms could be done by community, no need for Microsoft to do it.

#15

I would like to see that developers learn from existing frameworks and code, like WPF and Silverlight, rather than directly porting an old codebase. You know. A lot has happened since the start in 2007 (and earlier).

Have a look at Moonlight - open-source implementation of Silverlight. There is a lot to be learned from it.


#16

Can’t this be solved via Custom Renderers like in Xamarin.Forms?


#17

Only to some extent.

There are just too many places where you get 90% of the code done, and the 10% becomes very hard. So you either rewrite everything, or you end up with a subpar experience. Compare in Xamarin Studio the iOS designer property page (entirely native) vs the Android properties (using Xwt).

The kind of control that you need is just not there. This is why we are moving from one to the other.


#18

This “client side” is in System.Web too!
That is the reason for .net Core (modular, start small use what you need)

So why didn’t Microsoft make the client-side open source?

Backward compatibility? I don’t think that Microsoft wants to break .net on desktop and server (legacy ASP.net) just like that - that is the reason they do not accept pull request yet. I would not too.


#19

I really don’t get the use of a striped down .net like core, there are already a myriad of .net version targeting different level of hardware, did we need yet another one that removes more concepts? What for? I really don’t see how it changes anything in hosting scenarios which it seems to target (makes as little sense as the client Framework, lot of confusion for a few mb download saved in an era where it doesn’t matter for anyone).


#20

For desktop client and server side I can understand the urge to make it simple one framework 200MB and that’s it. But for mobile and IoT (where Microsoft aims) 200 MBs is not acceptable. Even in cloud every unnecessary processor tick leads to MegaWats of unnecessary power consumption and this is not eco friendly + this inhibits costs.

These are the reasons Microsoft started shuffling stuff around and this “start small add what you need” approach is good. The problem is that mobile and IoT as thecnologies came after desktop, so there is legacy technology.

It is easier for those that are starting from scratch - develop tech for IoT and mobile first and add pieces to it for desktop and server side. Microsoft could do it too simply start new project and name it “.new”, but I don’t think that would be great idea from marketing standpoint. But who knows


.NET Foundation Website | Blog | Projects | Code of Conduct