New Mono 1.2 Now Supports WinForms 304
smbarbour writes "The Mono project (the open-source .NET compatibility library acquired by Novell when Ximian was purchased) has released version 1.2. They are now including support for WinForms. Ars Technica has a detailed rundown on the new release. The Mono project supports Visual Basic.NET as well, so developers that use VB.NET now have the possibility of directly porting applications to Linux." From the article: "Relatively high memory consumption and performance bottlenecks are commonly perceived as being amongst Mono's most significant weaknesses. Some critics frequently refer to various performance issues to support arguments against broader adoption of Mono technology in open source projects, most notably within the GNOME community. The performance improvements in Mono 1.2 could potentially address such criticisms, but it is likely that a lot more work will be required before the problems are completely resolved."
Re:Indeed. (Score:3, Informative)
Re:Great, even more ways for MS to kill it (Score:5, Informative)
First some background information.
The
Mono implements the ECMA/ISO covered parts, as well as being a project that aims to implement the higher level blocks like ASP.NET, ADO.NET and Windows.Forms.
The Mono project has gone beyond both of those components and has developed and integrated third party class libraries, the most important being: Debugging APIs, integration with the Gnome platform (Accessibility, Pango rendering, Gdk/Gtk, Glade, GnomeUI), Mozilla, OpenGL, extensive database support (Microsoft only supports a couple of providers out of the box, while Mono has support for 11 different providers), our POSIX integration libraries and finally the embedded API (used to add scripting to applications and host the CLI, or for example as an embedded runtime in Apache).
The core of the
Basically a grant is given to anyone who want to implement those components for free and for any purpose.
The controversial elements are the ASP.NET, ADO.NET and Windows.Forms subsets. Those are convenient for people who need full compatibility with the Windows platform, but are not required for the open source Mono platform, nor integration with today's Mono's rich support of Linux.
The Mono strategy for dealing with these technologies is as follows: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.
The patents do not apply in countries where software patents are not allowed.
For Linux server and desktop development, we only need the ECMA components, and things that we have developed (like Gtk#) or Apache integration.
With the new Novell/Microsoft agreement, will the patent policy change?
Mono is a community project, and as such, we will continue to implement the policy of not integrating knowingly infringing code into Mono.
And we will continue to follow the steps outlined in the previous topic if code that potentially infringes is found: finding prior art, finding different implementation techniques, or if none of those are possible, removing the code from Mono.
Re:Very good! (Score:2, Informative)
"Windows Forums"?
You know, this has been my major concern with Mono -- moronic Visual Basic programmers migrating to Linux. And if spelling isn't enough:
Most software I use can be compiled with very little modification between Linux or OS X (using X11). I'm a Linux developer and I rarely touch kernel code, and then, only for fun. We have a local radio station that's running entirely on Ubuntu, without touching the kernel.
Implying that Linux development requires kernel hacking is worse than moronic -- it's infectiously moronic. You're spreading FUD, intentionally or not.
And may I ask, what is it that's stopped you from doing exactly what you described, but with Java instead of Mono/.NET?
Oh well, there's always the decent stuff: Beagle.
Misleading title, support is still incomplete. (Score:2, Informative)
ADO.NET, ASP.NET, System.Configuration, and Windows.Forms only contain partial support for 2.0 APIs, full support will only be available in Mono 2.0.
How partial is that support?
First try:
$ mono Test.exe
** (Test.exe:6411): WARNING **: Missing method System.Windows.Forms.ToolStripItem::set_ImageTran
Unhandled Exception: System.MissingMethodException: Method not found: 'System.Windows.Forms.ToolStripItem.set_ImageTran
at
at kk1.Test.Test..ctor () [0x00000]
at (wrapper remoting-invoke-with-check) kk1.Test.Test:.ctor ()
at kk1.Test.Program.Main () [0x00000]
Second try:
$ mono
Segmentation fault (core dumped)
So it seems that the header should really be "Mono now PARTIALLY supports WinForms".
Appropriately enough, the confirmation word is "roughly"
Re:Good for development purposes? (Score:3, Informative)
Comment removed (Score:4, Informative)
Re:Whats wrong with Java? (Score:1, Informative)
You obviously haven't used
Java is a tiny little resource-miser compared to
But you are right. Java is no slim jim compared to even C++ or Objective-C, let alone pure C.
Re:Whats wrong with Java? (Score:5, Informative)
I get a 22M RSS (280M total) for a Java application showing a single JButton in a JFrame; I get 7M RSS (22M total) for the same Gtk# application.
and has very mature gui compoenents in swing and awt that just work across platforms.
When I run a Swing application with Gtk LAF on my Linux box using Sun Java 5, it fails to pick up the Gtk theme I'm using, the menu buttons disappear when I click on them (because foreground/background seem to fail to pick up the right colors) and the menu shortcuts use the wrong font and wrong text. And that's just for starters. There is nothing "mature" about Java 5 on Linux, nor does it work in any form.
Java has its place in the world, and so does Mono, and they largely don't overlap.
Re:Sharp Develop (Score:5, Informative)
We will start work on Winforms 2.0 soon, SharpDevelop should work when Mono 2.0 comes out.
Re:Misleading title, support is still incomplete. (Score:5, Informative)
Re:Whats wrong with Java? (Score:3, Informative)
I program in Java and wouldn't touch Mono with a 10' pole, but Java really is a bloated pig at runtime.
Purging Mono (Score:3, Informative)
I dislike the situation too, but since the software I need to run on some servers only works on SLES or RHEL, I don't have many options. I certainly wouldn't run SuSE otherwise.
You can remove Mono from Ubuntu fairly easily, and I do. apt-get --purge remove mono-common will do the trick. You lose a couple of GNOME applications. I expect GNOME to become more infected in future releases following the Microsoft/Novell deal, in which case I'll probably go back to KDE.
Why not Java indeed! (Score:3, Informative)
Re:So what? (Score:3, Informative)
The point is that, IMO, Java trails
Getter/Setter methods are easy to generate and offer the exact same functionality.
At the cost of (arguably) reduced readability in many cases.
Re:So what? (Score:2, Informative)
Links:
http://www.theserverside.com/news/thread.tss?thre
http://blogs.sun.com/herbertc/entry/project_sempl
http://blogs.sun.com/roller/page/herbertc?entry=p
http://www.sitepoint.com/blogs/2006/05/19/write-j
http://vbwire.com/brief.asp?9342 [vbwire.com]
http://blogs.zdnet.com/Burnette/?p=107 [zdnet.com]
Re:So what? (Score:4, Informative)
FUD. There are some good graphical java apps. Look at Swing Sighting [sun.com] for examples.
Azureus is a well known app on SWT.
More FUD. You can use JNI api to make native calls, thought it is not automatic like calling a DLL from Visual Basic. You have to code the calls in C/C++.
FUDfest. Java 6 will have some desktop support. Apple had a Java implementations that blends with its desktop very well for years (I haven't seen this myself).
That is like open the gates of flames. Slow in which context, on which hardware, what app, what the load, to what are you comparing?
What do you mean? Eclipse is distributed as a zip on Windows. Doesn't even has an installer. You just unzip to install, and delete the dir to uninstall.
You seem to not know that the most use of Java is actually in server side apps, like web apps, web services, enterprise server... and mobile phones of course.
Re:So what? (Score:2, Informative)
Also in practice, a Set provides nothing that a Map with only keys and null values provides other than reduced memory utilization. Since the CLR already reduces memory utilization vs. Java, this isn't really a Java win.
Re:So what? (Score:4, Informative)
I do think the former is easier to read. It's not a big difference, but it's still easier.
I also think that a + b is easier to read than a.add(b). If there were a language that didn't support = operators at all, even for primitives, what would you think of it? Just as easy to read as if you went through and changed a.set(b) to a=b everywhere?
The other advantage I see properties having is the following: they let you use standard fields and later change them to be properties without changing any other code. Direct language support. If you want to be able to change representations, do extra processing, everything that using accessor methods gets you in Java, you either need to write it with setters and getters right from the start (and have corresponding code blowup... you're essentially writing the same thing three times; if Java had macros I would regularily use something like #define SG_FIELD(type, name) type name; void set##name(type new##name) { name = new##name; } type get##name() { return name; } to avoid the nonsense of writing the same thing over and over and freaking over again) or you need to use a tool that will automatically refactor the uses of a field to use setters and getters. Incidentally, Eclipse provides such a tool. Eclipse is a wonderful IDE, and was the reason that the work I did with Java a while ago was one of the more plesant programming experiences I've had despite (as you might be able to tell) being a fairly-big anti-fan of Java.
The issue of delegates I agree with to some degree, as it is nice syntactic sugar, but one that is, again, easily done equivalently well through the use of listener interfaces
Not always "easily". If you use interfaces, you have to use the function name provided, you can't give an arbitrary "call this function" construct. You can get around this with inner (and perhaps anonymous) classes, but at the expense of quite a bit more code.
It's Java's lack of delegates that is the reason that they need the nonsense like "you can subclass Thread or implement Runnable", "subclass WindowAdapter or implement WindowListener (oh, which BTW you'll have to implement all 10 methods even if you're only interested in one)", etc.
And, while I am at it - C#'s lack of a "throws" clause on functions is just as annoying.
I'll grant this one to you. Personally, I don't know where I stand with regards to checked exceptions. I'll agree that it can be nice in certain cases, but at the same time, it can be a big pain in the butt in others. One of my friends is doing a class project where they're looking at extending the Java language with something (I don't know exactly what they're doing, but it's something that relates to ensuring that cleanup code is run), and was telling me about a project that someone else worked on where they did a compromise. Basically, they make functions that could be called cross-module (read: package) checked, so you had to declare all possible exceptions that could leave that code. However, private and protected methods do not have to declare the exceptions that could be thrown, so a change to what one function does doesn't necessarily propagate to a zillion others. This to me sounds like a very reasonable compromise.
Of course, then you have C++, where the exception specifications are perhaps the worst-designed feature of the "++" part.
Now, if you are purely in your own code this isn't absolutely terrible, as you can just start digging and figure it out. However, if you are using any microsoft stuff, or any third party dlls, you are pretty much screwed
Okay, third party tools I'll again give you some (maybe most) of the time, but MS stuff? It's documented in the API reference plain as day. It's far easier to find that out than it would be to go through your code! You could make the argument that you don't know for sure that's all you have to deal with, but considering that the MSDN documentation is second to none in terms of quality, I don't think you have much to worry about there.
(Though I'll point out that the Java extension I mentioned above would apparently go a long way to solving your qualms)
Re:A framework of our own? (Score:1, Informative)
You mean like this? [wikipedia.org]
Re:Very good! (Score:3, Informative)
Skype.
Google Earth.
Re:So what? (Score:3, Informative)