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.
All of this will ship with our upcoming Mono 2.0 release.
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.
All of this will ship with our upcoming Mono 2.0 release.
Comments
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 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.
That's where I see the major difference in portability.
GTK# maybe? Seems to be highly extravagant on Windows, though...
Thanks.
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!
Where should we report this information to?
One thing that I had to use pinvoke for recently is selecting a window (user32.dll, GetCapture, WindowFromPoint)
btw. Congratulations, nice job
I can somehow imagine a lot of .NET code (especially buggy in-house apps) out there that rely on an underlying implementation of Win32 in order to function.
You can report it to me via monkey AT jpobst DOT com.
Thanks!
This is an important milestone for Mono..
and Keep it up
Congratulations
And when asp .net 2.0 full in mono
???
I would like to say special thanks for all of Mono WinForms tema.
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)
But keep it up! This is quite an amazing feat.