[Mono-dev] GSoC 2012 Proposal - WPF

[Lucas Zawacki]

Hello,

I'm Lucas Fialho Zawacki a Computer Science undergrad at UFRGS
university in Brazil. I have 4
years of experience as a programmer and I'm well versed in C/C++,
Ruby, Lua as well as some other languages.
I have a lot of experience with Windows programming, mostly because
I'm also a contributor to the Wine project and have worked with them
for last year's GSoC.

As you may know, Wine is not so useful when applications mix .NET with
native code and I've always wondered
why Mono couldn't help there. In the past few days I did the reading
about and I reckon the WPF would
help in this regard. From what I gather, there's little interest in
implementing this due to the size of the project and
the convergence with Silverlight. Well I'm interested.

I understand this is a huge undertaking so I ask for ways to limit the
scope of such a project to make it feasible in a summer? Maybe it's
possible to propose a "port" of the intersection the API has with
Moonlight?

I wait for your feedback. I'm also hanging around at #mono as 'lfz'.

Best regards
_______________________________________________
Mono-devel-list mailing list
Mono-de...@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Sharique uddin Ahmed Farooqui]

Hi Lucas,

Since you have already contributed in wine, I suggest you to look into
wine mono bridge, this will be very useful too run applications on
mono which use component which are already in mono like Winform, Gtk#
.. etc and those apps did not have a Linux version.

--
Sharique uddin Ahmed Farooqui
"Peace" is the Ultimate desire of mankind.

[Vincent Povirk]

Hi,

Since you're interested in Mono in Wine, I should probably explain the
current situation.

Currently, it's possible to install Mono for Windows in Wine, and
Wine's mscoree.dll will find the Mono install and use it to run .NET
code. This is not very useful because of incompatibilities and missing
libraries (notably WPF, msvcm, and XNA), and it tends to be confusing
for users, who have a choice of Mono and native .NET, though Wine will
always recommend Mono. Native .NET can only really be installed
properly via winetricks.

I'm working on a Mono package that will work similar to wine-gecko. It
will install automatically if native .NET is not present and include a
replacement for any MS .NET components that we can't use as-is (due to
licensing or compatibility problems). My hope is to create stubs for
msvcm, WPF, and XNA, so that those projects are slightly more
inviting. (Actually, for XNA I'm hoping to take advantage of MonoGame,
but I haven't yet done the research on making them binary compatible.)

The Mono community is generally not very interested in this, as they
are more focused on being a development platform than a compatibility
layer. This is working out very well for them, and Mono is very useful
as such, so I think that makes sense.

The Wine community is more interested in replacing .NET components
like WPF, but AFAIK none of us know any details of WPF's API, or what
you would have to do to implement it. So while the Wine project would
likely be interested in such a project, I don't think we could provide
much guidance with the technical issues around WPF specifically, or
how to properly scope the effort. So it is probably not a good project
right now, but it might be next year when the Mono packaging for Wine
will be further along.

We really need people who can work on .NET code for Wine, and I'm only
expecting that need to increase. So I'd like to help get you started,
but I fear there isn't much I can do. I'm sorry we're not yet prepared
for a gsoc project in this area.

I do remember asking about the possibility of porting parts of WPF in
Moonlight to work in plain Mono, and I was told it would be difficult
to separate them from Moonlight.

[Lucas Zawacki]

Thanks for the detailed explanation Vincent! Keep us posted on the
advances you make and maybe let's get in touch if you think that this
could be better resolved in the Wine side (even if it's a project
outside gsoc).

2012/3/28 Vincent Povirk <madew...@gmail.com>:

> I do remember asking about the possibility of porting parts of WPF in
> Moonlight to work in plain Mono, and I was told it would be difficult
> to separate them from Moonlight.

That's too bad, if someone is more familiar with the situation please
enlighten me.

[Alan]

Hey,

The short of it is, the scope of the project would be far too long for the SoC regardless of how feasible it is. It'd probably be one summers work to make moonlight run with a backend other than GTK in moonlights desktop mode, which'd be a requirement for your purposes. The other big issue is that the majority of all moonlight unit tests are no longer accessible by anyone as only Novell employees working on Moonlight had the right to access them. If future development were to take place, this test suite would have to be built up again, though that could be done as the new changes are implemented.

Nothing is stopping anyone from beginning this work. However the Mono Project itself does have a lot of projects which would be significantly higher priority to both us and the community. As such, it is unlikely this would be accepted as a SoC project.

Alan