Slashdot Log In
New Mono 1.2 Now Supports WinForms
Posted by
Zonk
on Fri Nov 10, 2006 05:19 PM
from the who-doesn't dept.
from the who-doesn't dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Great, even more ways for MS to kill it (Score:4, Insightful)
Re: (Score:2)
While the concept of what mono offered was a great idea, the risks are far greater. just choose something like python instead. Its also cross compatible and i dont think the rug can be pulled out from underneath you at the last minute.
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.
Parent
Re:Great, even more ways for MS to kill it (Score:4, Insightful)
Rich.
Parent
Re:Great, even more ways for MS to kill it (Score:5, Interesting)
http://techupdate.zdnet.com/techupdate/stories/ma
This was pointed out years ago. No, how long does this agreement last? The answer is, as long as Microsoft wants it to. Should Microsoft revoke this agreement, or initiate a revocation, then the worst that will happen is that the ECMA standards will be revoked. The ECMA wording on this is pathetically weak and under no circumstances gives a legally binding long-term guarantee. This is why we had all that rubbish about a 'letter from Microsoft' that didn't materialise some time back:
http://www.ecma-international.org/memento/codeofc
The whole 'ECMA is safe' thing is what the Mono people would have you believe. It isn't. The RAND stuff is double speak, because Microsoft do have patents that are specific to implementing
It's actually more likely that the Microsoft specific stuff like ADO.Net, ASP.Net and Windows.Forms are safer since these are only namespaces in an API, although their patents basically say that if you're implementing
Parent
FUD (Score:5, Insightful)
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.
Parent
be specific (Score:4, Interesting)
* 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.
Parent
Re: (Score:2, Interesting)
Maybe that's why they signed the agreement with MS (Score:2)
Re: (Score:2, Insightful)
Maybe I can Finally Get Imeem Running ON Linux (Score:2)
Very good! (Score:5, Interesting)
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.
Re: (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
Why not Java indeed! (Score:3, Informative)
Re: (Score:2)
This one looks too dangerous to risk. It *MIGHT* be safe... but "do you feel lucky?".
MS has issued a clear warning that is some project becomes popular, they will bankrupt it. Exactly which patents might be used aren't obvious, but there have long been suspicions that MS has some patents covering parts of
Re:Very good! (Score:5, Insightful)
Parent
Re: (Score:3, Insightful)
VB6 and previous were shitty. VB.NET is good stuff that looks shitty.
Re:Very good! (Score:5, Insightful)
Let alone the other things that a good IDE will give you like refactoring support.
Parent
Re: (Score:3, Informative)
Skype.
Google Earth.
Indeed. (Score:5, Interesting)
And now with
Re: (Score:3, Informative)
.NET 3 (Score:3, Insightful)
Indeed, this is NOT NEWS (Score:2)
Apparently, these people either never heard of Mono before, or assumed it was an STD. Really, nothing has changed -- it's just getting a little better and a little more complete. Basically, it's like Wine, only it might take on a life of its own outside of simply allowing Windows programs to work elsewhere.
I doubt it, though. Right now, my money's on Perl6.
Re:Indeed. (Score:4, Interesting)
Thats for the language. ASP.NET 1 is really where the garbage was (the above was mostly that the languages weren't mature enough). The page model was horrible in every ways, shape, or forms.
Visual Studio 2002/2003 was a fairly poor and feature-lacking IDE, too (and lets face it: in the microsoft world, the IDE is part of the environment).
I guess the reason I felt that way, was that Java 1.5 came out not that long after
If you did
Don't get me wrong, if you look at my posting history, I'm starting to have a reputation to being a Microsoft butt kisser, so I'm definately not biaised against them. I just feel
Parent
Nono (Score:2, Funny)
Sharp Develop (Score:2, Interesting)
Re:Sharp Develop (Score:5, Informative)
We will start work on Winforms 2.0 soon, SharpDevelop should work when Mono 2.0 comes out.
Parent
Query: (Score:2)
I haven't really been following Mono, or .NET, but upon reading this I was suddenly reminded of the story from a couple days ago about Novel and Microsoft getting into bed together. [slashdot.org]
Now, I'm sure a number of anti-microsoft fanboi-types will automatically jump all over this, but I'm hoping that someone who isn't a member of that group can explain to me if .Net (and sorta by extension, Mono) is a big enough deal to Microsoft that they would worm their way into this solely for the purposes of shitcanning Mono
Here's a better suggestion... (Score:2, Insightful)
Re:Here's a better suggestion... (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
A framework of our own? (Score:3, Interesting)
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/ [digitalelite.com]
Re:A framework of our own? (Score:4, Interesting)
Python is to Linux as VB is to Windows. That has its place, and I'm glad it's there, but I mean a framework that would have compile to a VM that sits above the OS (perhaps even in userspace!) and that has bindings for c#, python, ruby, smalltalk, etc...).
I haven't thought through the details fully, and I could be totally wrong (wouldn't be the first time) but I don't know of anything that makes coding on Linux as easy as coding against
Consider this the feedback of a Windows developer by trade who uses Linux exclusively at home. Anecdotal, but it's the opinion of many/most Windows developers. And they often won't go with mono becuase mono is consistently about 15 months behind MS in its API.
Tom Caudron
http://tom.digitalelite.com/ [digitalelite.com]
Parent
The more the merrier (Score:4, Interesting)
Re: (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
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 peop
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
Re: (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: (Score:3, Insightful)
Two things I can think of offhand that Java has an upper hand with are more powerful enums (here's an example [arstechnica.com]) 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, pas
Re: (Score:3, Interesting)
So, let me see if I got this straight...
... I am afraid we don't quite see eye to eye on this one. 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. Admittedly, it uses more lines of code, but it also guarantees that people actuall
obj.setProperty(sampleValue);
is harder to read than
obj.Property = sampleValue;
Yeah
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)
Parent
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.
Parent
Re: (Score:3, Informative)
Re:Whats wrong with Java? (Score:4, Informative)
I don't care if the code is aged, I want it to work.
Parent
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.
Parent
Re: (Score:3, Interesting)
My anicdotal evidence suggests that
Let's see some benchmarks to support your claims.
Re: (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.
Re:Misleading title, support is still incomplete. (Score:5, Informative)
Parent
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 r