The Mono 1.0 is quickly approaching. This document explains the Beta releases that we will be doing as well as the various code freezes that we will have in place. Mono 1.0 supports most of the features of the .NET Framework 1.0/1.1 with a few exceptions.
Some of those features will be available in “preview” mode for this release, but are not going to be officially supported. For a detailed list see the Mono
Roadmap and the detailed list of assemblies.
Mono 1.0 Beta and Rollout Schedule
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I read that Mac OS X 10.3 will be supported with binaries from Ximian. That’s nice, but I still wish they had a native GUI toolkit for OSX though (Cocoa#?).
Also, it would be nice to have binaries for FreeBSD too.
Looking forward for the release!
Very cool, I’m excited. Given that much time hopefully we can squash an enormous amount of bugs.
just curious – what constitutes a 1.0 release?
Is Apple contributing to the Mono project?
Have a look here:
http://www.go-mono.com/mono-roadmap.html
The standard widget toolkit for .NET is Windows Forms. Given the difficult to carry out a FOSS implementation (which involves Wine), the Ximian guys decided to throw in support for another well known toolkit: Gtk. Hence, there is a full set of wrapper classes for Gtk, known as Gtk#.
So these two widget sets are the ‘standard’ toolkits officially supported by Mono.
At this moment, you would depend on having a working Gtk installation on your Mac to do any GUI development with Mono, but someone could very well come up with cocoa#, just like existing wrappers for Qt and WxWindows (currently running under Mono and Portable.NET)
Epaminonda, thanks for the reply, but all this, I know.
I in fact doing some hobby programming with GTK# on Linux.
My comment was about directly asking people to create a _native_ Mono toolkit for OSX, maybe by using Cocoa, not by using GTK# under X11 with GTK/Gnome. Anything under X11 on OSX, is just not as elegant as a native app.
Haha, this is very cool. Especially if it works no osx, i’ll test that out later. A cocoa# library would be nice, or an objective-c binding if that isn’t possible.
what about the #widget toolkit?
http://www.icsharpcode.net/OpenSource/SharpWT/default.aspx
it’s supposed to be a port of Java SWT, so you can run native widgets cross platform. if this works out to be good, powerful, easy to use and fast, we might as well ditch system.windows.forms and just use this (to promote cross-platform apps!).
What is gecko-sharp? It’s mentioned in the first document. Som sort of mozilla binding?
Quite right Eugenia. What the Ximian people should have done was turn the Mono Windows.Forms implementation into a totally GUI independent implementation that anything could have plugged into. You would have seen many people, desktops and projects flocking to support Mono. Mono really should have been a very integrative toolkit and environment that could really bring things, people and projects together. Miguel has totally and utterly misunderstood this, and he keeps missing the boat.
Unfortunately, the Ximian people, like Microsoft, want you to use what they want you to use – namely that, somewhat less than perfect graphical toolkit, GTK.
Unfortunately, people on Windows will be using Microsoft’s Windows.Forms. Running MS Windows.Forms means Wine on Linux/Unix, which you can never rely on. No one outside of the Gnome/GTK world (commercially that is) will use GTK.
Mono has totally missed the boat on being the one (that joke isn’t lost on people) integrative technology – the missing glue if you like. Mono is currently a dictative technology, in the manner of those from Microsoft. No one in the open source or commercial world will be dictated to though, and for it to ever be accepted in the commercial world (or even outside of the Gnome/GTK open source world) as it stands Mono will need to be much more integrative and less dictative. In that sense Mono is already an absolute monumental failure that will always be ‘on the verge of something big’.
Windows.Forms, Gtk# and other toolkits have very very different implementations. You can’t make interfaces and let people chose the toolkit they want.
If you want to have support for Windows.Forms, use Wine, if you want to use Mono with Qt, develop QT# bindings to Qt…
Ximian didn’t really had choice, they made what they had to do.
Just cut that crap will you, MONO is 100% own by Open Source because of ECMA, not like Java that own by Sun. And we love Mono and it have great technology for us to use and give us so many option to choose like GTK#, QT#, SWF, and now Cocoa#.
I don’t blame anyone. But hey either we want FLOSS to be more popular or what??
We have Wx.NET, GTK#, QT#, KIMONO, FOX.NET, FLTK.NET [that is a wrapper for every GUI toolkit outhere]
but not one for SWF. [that could be based on wxWidgets {that gives native format for both Windows and GTK/Linux}]
That way One can design in VS.NET 2003 and just copy paste the code and it would be ready to run under GNU/Linux..
He could even that wxSWF wrapper to compile it for Windows!
So why all the fuss about all this wrapper, and not ONE that would have the EXACT syntax as SWF has?
I don’t get it. SWF names could not be patented because the names are common english [button, textbox etc..]
Any ideas why this doesn’t happen?
I notice that System.IO is missing from the list of assemblies. Will this be included as well ?
Take a look at some of the deeper areas of the System.Windows.Forms API. There are all kinds of windows-specific concepts such as handles, WndProc, even pointers. To make 100% of all SWF applications run on other platforms, you need a complete implementation of the win32 API. That is why mono is using wine.
There is a reason why it is called *Windows* Forms. It is not designed as a crossplatform toolkit.
I find the list of assemblies to be rather shallow, instead of detailed. Are all of the assemblies which are claimed stable FULLY implemented?
“Mono 1.0 supports most of the features of the .NET Framework 1.0/1.1 with a few exceptions. ”
Those exceptions (like Windows forms) who will be used extensively by Microsoft to make Windows C# programs not portable…
System.IO is a namespace in the Mono System assembly. The list linked in the artcile only tells you which assemblies will be included in Mono 1.0. An example: System.XML in an assembly that happens to also include the System.Xml namespace, but also contains for example the Mono.Xml namespace. Confused yet?
Short story: Yes, System.IO will be included. And a lot more.
Windows.Forms, Gtk# and other toolkits have very very different implementations. You can’t make interfaces and let people chose the toolkit they want.
You can allow for different implementations, since all ‘windows’ toolkits in what they do are similar. It would have been quite easy to allow for different implemenations, and for Mono to take a much more integrative back-seat. It would have been a killer.
Ximian didn’t really had choice, they made what they had to do.
Yes they did.
Just cut that crap will you, MONO is 100% own by Open Source because of ECMA, not like Java that own by Sun.
Would you cut the crap and try and read what I’ve written? I didn’t doubt that Mono is an open source project, I’m not interested in the ECMA since it doesn’t really mean anything (proprietary stuff written on top – Microsoft) and I couldn’t care a less about Java either. I’m talking about how Mono is positioned and developed. At the moment, however good it is, it will do nothing for free and open source software.
And we love Mono and it have great technology for us to use and give us so many option to choose like GTK#, QT#, SWF, and now Cocoa#.
Mono could have been a much more integrative technology for all of this. However, Mono just favours GTK and the implementations of what Ximian prefers. A lot of this graphical toolkit stuff needs to provide a base at a higher level for different implementations, so that they can all still work together – diversity is the way that open source software works. Sorry, but people are not going to throw in the towel for GTK or anything else – open source software needs to be inclusive.
There is a reason why it is called *Windows* Forms. It is not designed as a crossplatform toolkit.
There are all kinds of windows-specific concepts such as handles, WndProc, even pointers.
I’m glad someone has pointed this out. You simply can’t just migrate Windows.Forms to GTK#, SWF, or Qt# – or even one to the other. This is why Mono had a huge opportunity to be an integrative technology and provide an open-source united-front on this issue.
You’re so right!!! Or we could copy off of Sun. Let’s use JAVA instead! Because damn, Sun is soooo cool!
“I’m glad someone has pointed this out. You simply can’t just migrate Windows.Forms to GTK#, SWF, or Qt# – or even one to the other. This is why Mono had a huge opportunity to be an integrative technology and provide an open-source united-front on this issue. ”
Yes, it would have been nice if ximian had developed something new and revolutionary instead of just slapping a wrapper on GTK.
But you have to understand that ximian is a for-profit corporation and they need some return on investment for the mono project. The fastest and most straightforward way to use mono productively was to create a GTK wrapper, and that is exactly what they did.
They have already done a great service to the open source community by producing a high quality .NET VM and various low-level libraries.
For those that want System.Windows.Forms that don’t depend on Wine you might want to check out DotGNU’s implementation of it. It rides on top of X on Unix and GDI(I think) on windows.
It’s not going to look native on any platform and to get it work on Mono might take a little fiddling around. I’ve never tried it but I’ve heard that it involved swapping out Mono’s System.Drawing assembly and maybe a couple other things.
There is(was?) a mono subjproject to write a version of System.Windows.Form on top of gtk#. I think that effort is pretty much dead but I think that the code is still there.
At first I wondered why Mono didn’t implement SWF on top of straight gtk+(not gtk#). That way, it would look native on windows and unix. One answer is that De Icaza isn’t a big fan of SWF and the other is more of a political reason. They wanted to offer the Gnome people an easy migration path and gtk# affords them that somewhat.
Of course there is always wxWidget.NET which seems to be pretty feature complete and with that new SMOKE library(which I have not tried), there should be decent QT/KDE(?) bindings in the near future. I think Qt bindings for .NET would be awesome if Trolltech would offer an uptodate version of Qt for windows.
You can brose the assembly status one by one on the
web site, its at the bottom of the left-side menu.
For example, the “mscorlib” assembly status is reported
here:
http://www.go-mono.com/class-status-corlib.html
More details were posted to the mailing list, with
specific known issues.
Dear Lumbergh,
You are incorrect about your portrayal of why S.W.F was
done using Wine and not Gtk#. Am not a fan of S.W.F, because it is really not a great API to develop software with. Still, we are funding three developers to work full time on implementing SWF/SD and only one to bind Gtk+.
The issue is whether you want to run small samples from books, or you want to be able to run WebMatrix out of the box on Linux. For the later, you will need the Wine-based SWF as opposed to just a small and portable implementation.
Is binding Gtk+ simpler? Of course, and it is already much more functional and will be in 1.0 shape by the time of the Mono 1.0 release. SWF wont reach stable state until our Mono 1.2 release in December this year.
That being said, SWF is a short-term solution, it has a lifespan of 3-5 years, as Microsoft’s new UI widget set is comming out in 2006.
Miguel.
Portable.NET has a “themable” S.W.F interface – you can hook it into whatever drawing interface you want, baby, GTK, Win32, QT – you name it, you got it. Someone is already working on a integrating P.Net’s themeing engine with Qt for native looking, native acting Linux applications! This is perhaps in line with Portable.Net’s design of portability and extensability. Really good stuff, I wish the Mono team and DotGNU were working together on S.W.F.
#WT is a dead duck – it never got anywhere.
FOX.NET / FLTK.NET are nothing more than pretty screenshots with no code and no CVS/SVN repositories.
They should have versined Mono like this.
Mono 1.0 (Compatible with .NET 1.0)
Mono 1.1 (Compatible with .NET 1.1)
Mono 2.0 (Compatible with .NET 2.0 [Longhorn])
They way they are versioning it right now will create a lot of confusion. Another problem with Mono is that they added classes to namespaces other than the Mono namespace, which means that someone might use System.Foobar. Oviously, it will not run on .NET because System.Foobar doesn’t exist in .NET.
Obviously I think a lot of us would really like the cross-platform ability without having to write to a different toolkit for each platform. I’m not sure this is the best since Java has shown that having a cross platform toolkit can be somewhat limiting on all the platforms but I’m still curious if there will be any options. The most obvious thing to me (which isn’t saying much) is that there is some kind of GTK port that runs on windows, mabey using the native windows widgets? I know there is a GTK port to windows and an underdeveloped Mac OS X port. What are the chances that these could be used in making GTK# cross platform. As I see it the greatest thing that mono could be is cross platform since that could have a lot of draw to developers and could make mono the implementation of choice. I sure would appreciate some feedback on efforts to make the visual side of mono cross platform (or is it accepted that the best way of doing it would to use the native widgets for each platform?).
You are incorrect about your portrayal of why S.W.F was
done using Wine and not Gtk#. Am not a fan of S.W.F, because it is really not a great API to develop software with. Still, we are funding three developers to work full time on implementing SWF/SD and only one to bind Gtk+.
I should not have lumped in the reasons for developing gtk# with the reasons that SWF was implemented the way it was. I think you’ll agree, and as I stated, that gtk# is for the Gnome/Gtk+ people and SWF is a separate thing all together. I should have clarified what I said.
I’m well aware of the needs for wine so that you can get 100% binary compatibility(which is going to be a crap shoot from app to app anyway you look at it). I was just pointing out that for those that didn’t need pinvoke there is(was) a branch of SWF that used gtk# as it’s backend.
It’ll be interesting to see what kind of .NET program run out of the box on Mono with Mono SWF/wine without having any kinds of problems.
I was not aware of Pnet’s themable support in their SWF implementation. It must be something new. Sounds very interesting though. I’ll defintely have to check it out. Of course since Mono is more feature-complete and faster I’ll have to figure out the exact steps to get it running under Mono.
“I was not aware of Pnet’s themable support in their SWF implementation. It must be something new. Sounds very interesting though. I’ll defintely have to check it out. Of course since Mono is more feature-complete and faster I’ll have to figure out the exact steps to get it running under Mono.”
Old. Damn old. That’s how the entire S.W.F thing was developed around for portability’s sake, y’know? But, it suffered a lack of interest, you know, one of those, “It doesn’t scratch my itch, so I won’t work on it” things that seems to gobble up the even the best laid plans. They honestly don’t pimp it as much as they should.
I realized that there was some sort of themable code in pnet, but wasn’t aware that it was actually workingl
I guess someone has just discovered the “report abuse” button and is randomly walkingg through the threads reporting nearly anything as abuse….Is it abuse when the chief author of Mono posts to clarify issues about that which he and others created?
Although I do not see it happening now I also hope that the DOTgnu folks and Mono can find more common ground in the future. Keep up the good work Miguel…