Search This Blog

The Big Finale

Last night, we hit a very important milestone in our support for Winforms. We are API complete, which means that our public API is exactly the same as .Net's (all 12,776 methods).

I wasn't around at the time, but the first check-in of Winforms occurred on July 8th, 2004, meaning it has taken almost 4 years to implement. Since then, there has been 6,434 commits to Winforms.

Thank you to everyone who helped us get here! Thank you people who contributed code! Thank you people who contributed tests! Thank you people who contributed Bugzilla reports!

What's next? Well, as with your typical 115k line cross-platform windowing/widget kit, there are bound to be bugs. So we'll be working to fix those. If you come across any, please report them so we can fix them too! Go here to report them.

I'm long since eager to write cross-platform GUI code, so are there any estimates on when a reasonable subset of the Avalon framework (WPF) will be available? WinForms, as far as I can see, would not port — the show stops on the first Handle use and WinAPI platform call.

You can use handles in Winforms, they just do not map to an actual HWND on non-Win32 systems, but you can definitely use them, and you can even override WndProc methods on derived classes from Control and process a pile of WM_ messages that Mono's Winforms actually builds on.

You certainly can not P/Invoke and get portable software; The same is true of WPF: if you P/Invoke with WPF, you will not get portable software (well, if you use WPF today, you do not get portable software to begin with ;-).

We currently do not have plans/staffing to work on WPF, so its up to the community to step up to the challenge if they want a WPF implementation.

But we do have a Silverlight implementation, so maybe that will do for now.

Avalon is managed code all the way through that you can reach (put aside bitmap-effects and such). From one side, this means it's highly portable. From the other, it allows to write UI without ever reverting to PInvoke for purely visual/behavioral things.

WinForms-on-Windows, being a thin layer on top of PInvoke, forces into calling right thru it, into the platform implementation, for the missing or misinterpreted pieces of functionality.

WinForms-on-Windows, being a thin layer on top of PInvoke, forces into calling right thru it, into the platform implementation, for the missing or misinterpreted pieces of functionality.

I hear people mention this, but have rarely seen anyone actually use it.

However, we are interested in supporting common use cases if anyone has any. Ie: we would create a managed library/function that would p/invoke the native stuff on .Net and replicate the same behavior on Mono.

If someone can point to some needed functionality that is commonly p/invoked to get, please do. Thanks!

That's impressive, a great step for the project!Does this mean that now all .Net Applications using Windows.Forms will work with mono? (Like Paint.Net, the application I missed most using mono and Linux)

Popular posts from this blog

One cool new feature in Visual Studio 2010 is enhanced Multi Targeting. Presumably, its all about allowing developers to target both the 2.0 and 4.0 runtimes from VS2010, but what it really means is you can easily target Mono from within Visual Studio 2010.

Like this:

To enable this, you need to unzip this file to:C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile

Once you do that, you can take your .NET project:

Go to project properties and switch it to the Mono 2.4 Profile:

Now it will compile using Mono's assemblies, and will flag methods that Mono does not contain, like thus:

This also works for Intellisense:

And Object Browser:

We are very excited about this feature, which should make it easy for people to ensure they are staying compatible with the Mono subset of the .NET framework without leaving Visual Studio. Once VS2010 is released, we will hopefully release the profile packs as we release each Mono version!

Over the holiday break, I stumbled upon this article from OSNews stating that there was a need for something like Paint.NET for Gtk. Having some experience with porting Paint.NET to Mono Winforms before, I knew that that was a massive task. But it still got me curious about Cairo and creating a layered canvas, since I had never played with Cairo or Gtk.

After playing around for a few hours, I actually had a working paintbrush and canvas. Intrigued by my success, I played around with it for a few more days. By the end of the week I had a nifty little paint program with a few features. Now, a month later, it's time to open my little project up to the world: Pinta.

Pinta is a clone of Paint.NET. It already has a small, but hopefully useful, set of features like multiple layers and infinite levels of Undo/Redo.

I hope to implement the same feature set as Paint.NET. Currently there are several tools missing, as well as adjustments like brightness/contrast and levels and Paint.NET…

As part of this year's Google Summer of Code, there were two projects that got chosen that were on my personal 'to-do' list. I was happy these projects got chosen because frankly, my to-do list is not getting shorter nor are the days getting longer.

One of these is Ed Ropple's "Cloverleaf", which is an add-in to Visual Studio designed to facilitate writing and testing applications in Mono. We decided on the following features:

- Test in Mono: Clicking this would run the current solution/project on the Mono runtime on Windows.- Scan with MoMA/Gendarme: Clicking this would run MoMA or Gendarme (which can run MoMA) on the solution/project.- Test on Linux: Clicking this would take the solution/project output and copy it to a Linux machine or virtual machine, and automatically start it.

Ed did some great work over the summer, so for my Hack Week project I started polishing and packaging his code so we could get it into people's hands. Unfortunately, I only got…