Slashdot Mirror
New Mono 1.2 Now Supports WinForms
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."
So now not only do we have to wait for submarine patents on C# and the runtime, now they can hit us on anything in their API as well. Especially with the Novell deal, people ought to realize that MS is just waiting for a chance to use their patents against open source. This is turning a bad idea worse. Just say no to Mono.
I still have more fans than freaks. WTF is wrong with you people?
I want to be able to develop applications in both Windows and Linux. VS.Net and Mono allow me to use the same code with very little tweaking between platforms and keep using my Visual BASIC skills I learned over a decade ago.
Windows Forums means I don't have to rewrite part of the program that uses forms for Linux.
I hope this gets more VS.Net developers porting over to Linux using Mono. Linux can really use more easy to use and easy to develop applications without having to learn kernel hacking and methods that exist only for Linux. This is a good thing and maybe the corporations will decide to have some Linux workstations if they can develop VB.Net applications for them the same way they develop them for Windows.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
This is a pretty cool project, and its coming along nicely. I really want to see it succeed, because that would allow me to spread my skills to a wider array of customers. Unfortunately, in its current state, MONO is only a partial implementation of .NET 1. And honestly: .NET 1 was garbage, and the vast majority of software that had the unfortunate badluck of being developped under it have been upgraded to the excellent .NET 2 by now (it is rare that apps get updated that quickly, for example between different java version.).
.NET 3 out (which is only an extension of .NET 2, not an actual new version of the framework...dumbass marketing idiots at microsoft), .NET 2 is even more important.
And now with
If you use Beagle for searching you do.
There are some cool mono projects out there. Now if they would just create a native compiler for mono programs so I don't have to have the entire run-time installed that would be great.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
This is Monkey business.
so does this mean sharp develop will now run on mono?
My keyboads not woking popely.
its not just an 'extension', its a vehicle to kill off pre XP machines.
---- Booth was a patriot ----
From mono 1.20 release notes:
s parentColor(Color) in assembly /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b7 7a5c561934e089/System.Windows.Forms.dll, referenced in assembly /path/to/Test.exe
s parentColor'.
/mnt/win/Program\ Files/kk1/anotherprog.exe
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"
One of the major points of the .NET framework is having multiple languages being able to compile to same bytecode. The implementation of Mono or .NET has nothing to do with which high-level languages utilize it, therefore dumping VB.NET over C# doesn't buy you anything. In fact, having more languages to choose from encourages development using Mono...and if you don't like VB or C# or managed C++, you can make your own language, as long as it can be described by the semantics of the CLR.
The "real" .NET framework supports C/C++, but also a total of, at last count, 44 languages (give or take a few since last i checked). Removing any of them really goes against the whole idea.
legacy ASP can run on Linux using third party tools. However, Mono, as far as I can tell, is unrelated to it. ASP and ASP.NET are about as close to each other as Java is to Javascript.
I don't care if the code is aged, I want it to work.
Change is certain; progress is not obligatory.
It uses less memory than Mono
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.
FUD.
.net's memory consumption is very reasonable and we all have anicdotal evidence that Java is a memory hog.
My anicdotal evidence suggests that
Let's see some benchmarks to support your claims.
http://brandonbloom.name
Properties (well that's how C# is better).
I'm a developer. I've made considerable money as a .NET developer, specifically, and while I am fully entrenched in the Free Software camp, I admit that I like the.NET framework overall. That said ... ...The open source community has some of the best and brightest minds in the software world involved in its improvement. So the question that naturally follows is, "Why haven't we designed and implemented our own framework?"
.NET/Mono endlessly as to which is best for Linux development, which is faster, which is easier, which is just plain better. Write in whatever language you want, but write to the framework that best opens Linux up the developer. Without question, that would be the framework that was written specifically for it.
Seriously, we spend endless hours debating which is less evil---java or mono---and we complain that both don't offer us the flexibility we have grown accustomed to in the F/OSS world, so why haven't we just started from scratch and done our own linux-centric framework to ease RAD work and simplify the task of getting started in Linux development.
I'm not suggesting it has a place everywhere. Certainly most kernel work and most driver work would need to stay C-based, but if we had a framework designed from the ground up to open Gnome and KDE devlopment (well, userspace development in general, really) it would get used. There's obviously a market for it. Developers argue over Java and
I dunno. There may be good reasons, but I don't see them from my vantage point.
Til I see a solid and Free alternative, I'm gonna stick with Mono (which I'm impressed with so far), but I'll keep my eye out.
Tom Caudron
http://tom.digitalelite.com/
-Tom
Microsoft has made it abundantly clear that when you implement the the ECMA stuff, and your own CLR, you are entering into a RAND agreement with Microsoft, and they have patents essential to the running of it:
It doesn't matter what Microsoft "makes clear", they are simply spreading FUD, and so are you. You don't enter into agreements by implementing a public standard. You may be infringing on their patents, but given the vast amount of prior art, it seems unlikely that Mono is infringing on any claim that would hold up. And Microsoft's statement of terms may not be satisfying, but a court would take it into account if there ever were a lawsuit.
And what's the alternative? Sun has many patents on Java, has actively defended their intellectual property against FOSS projects, and open source implementations need to implement the entire Java platform in order to be useful.
Mono, in contrast, is a separate implementation, under an open source license, based largely on its own APIs and libraries. Also, Microsoft's patents have been scrutinized in detail.
The situation may not be very satisfying, but for anybody wanting something faster than Python and higher level than C++, the choices come down to Java and C#. Technically, I think C# is superior, and at least for now, the legal situation surrounding it is also better than Java.
People like you produce a lot of hot air, but please be specific for once:
* Which patents is Mono suppose to be violating?
* What reasons does anybody have to believe that those patents actually are worth the paper they're written on?
* Given Microsoft's royalty-free licensing terms, what argument could they possibly make to a judge about damages?
* Why do you believe that those patents are hard to work around should Microsoft be insane enough to assert them?
* Which modern platform is guaranteed to be free from potential patent claims (from Microsoft or anybody else), and where is the evidence?
If people like you can't provide clear, convincing answers to these questions, then we might as well stick with Mono for the time being.
The benchmarks at the shootout suggest otherwise. C# and Mono beats Java for memory usage in just about every case, usually by a factor of 2.
I program in Java and wouldn't touch Mono with a 10' pole, but Java really is a bloated pig at runtime.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
There's basically no way to remove Mono from SLES without breaking YaST2... or at least, breaking it more than it is anyway, ho hum.
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.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
My requirements for leaving Win32 and GDI are 1) hardware-assisted scrolling, 2) fast blit of memory frame buffer where I can set the pixels, and 3) vertical sync-locked screen updates. Java Swing can do 1) with Graphics.copyArea(), 2) with BufferedImage, VolatileImage, and while Swing only offers BufferStrategy on full-screen Windows, I have written a Linux-X11-OpenGLX vertical sync checker and access it with JNI. Furthermore, the heretofore pokey horizontal scrolls and partial screen updates in X11 are now hardware accelerated using OpenGL in Linux Java 1.5. These Win32 capabilities (ScrollWindowEx(), CreateDIBSection(), IDirectDraw::WaitforVerticalRetrace()) that got removed, crippled, or marked as "unsafe code" in WinForms are available in Java and portable between Windows and Linux. Now that Sun is claiming to be open-sourcing the Java VM, and WinForms is supposed to get replaced by who-knows-what-Aero-in-Vista, and Netbeans has a GUI form designer indistinguishable from VB, I say why not Java indeed!
Java will have those incorporated in short order, i'm sure.
.Net in terms of design. I know of nothing that I would consider an advantage in language design to Java over C#, and many advantages to C#. Some are at the level of syntactic sugar (like properties or operator overloading), some are much deeper (like delegates).
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.
Just use Netbeans which can use VB 6 and build java apps.
a d_id=40344
i ce_visual_basic_for
r oject_semplice_visual_basic_for
a va-web-apps-in-visual-basic-or-javascript/
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
http://blogs.zdnet.com/Burnette/?p=107
As a professional Qt developer, I have a great number of clients who come to me to get out of the .NET trap. They were promised by Bill Gates and Miguel Icaza that .NET was transparently crossplatform. That it was a fully open standard. That there were not any performance or memory problems. Companies too cheap to upgrade from freebiee VS Express are forking over the cash for single-platform Qt licenses. Why? Because Qt is turning out to be THE native C++ API for Windows, Mac and Unix.
Don't blame me, I didn't vote for either of them!
Let me guess all your getters and setters did was set and get an instance var. What are the odds that the compiler, knowing you were using a getter/setter, and knowing that it didn't actually do anything, optimized away the function call overhead (that it couldn't optimize with your informal getters and setters)? Nope that can't be it, it must be that C# functions are extra-slow.
Why not fork?
Valid comment. (I cannot believe they marked you as flame bait for this.)
There aren't that many Mono users out there yet because of a few reasons. First off, the GIMP toolkit looks like crap. (That's a fact, not an opinion.) The only Mono GUI app I've seen is F-Spot, which I won't use due to its poor UI.
Now that Winforms are supported, maybe peeps on the Wintendo side of things can get a decent looking GUI app built in Mono. I suppose we *nix folks would be stuck with GTK+ apps, but then at least some people would get looks.
I would love to get myself off of the wierdo-language constructs of Java and into C#/Mono, but couldn't until now, without relinquishing some serious L&F qualities.
The Kai's Semi-Updated Website Thingy
I know of nothing that I would consider an advantage in language design to Java over C#, and many advantages to C#.
Two things I can think of offhand that Java has an upper hand with are more powerful enums (here's an example) and a much stronger Collections library (C# is notably lacking a Set collection).
However, as of late I certainly agree with you. I keep seeing "new" features in Java that it lacked until C# (especially 2.0) came out (though it's still missing some nice things like partial classes, passing-by-reference, and variable-length argument lists). Another example of why it's good to have options/competition. Personally, I find C# much more intuitive and easy to develop with than Java.
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
FUD. There are some good graphical java apps. Look at Swing Sighting 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.
"I think this line is mostly filler"
In practice, the object typedness of java enumerators does not make up for the them being harder to map into native code (C enumerators and C# enumerators are almost identical) and being unable to be used as flags.
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.
obj.setProperty(sampleValue);
is harder to read than
obj.Property = sampleValue;
Yeah
And, while I am at it - C#'s lack of a "throws" clause on functions is just as annoying. In Java, I have a programmatic way of knowing what exceptions to expect from a function (other than runtime ones, of course). In C#, I have to guess
... Yeah ... I am afraid we don't quite see eye to eye on this one.
;-)
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)
GTK looks like whatever theme engine you apply to it. If it looks like crap it's because you have bad taste. If you mean it looks like crap from an API/programmer standpoint (C) then why not look into some bindings.
> if it's something everyone thinks then you can call it a fact.
No, then it's a widely held opinion. But still an opinion.
Advanced users are users too!