Mono's WinForms 2.0 Implementation Completed

adrian.henke writes "After four years of development, 115K lines of source code, and 6,434 commits, Jonathan Pobst announces that Mono's WinForms 2.0 implementation is now complete. This announcement has been long awaited by any .NET WinForms developer who has ever tried to get an applications to work on Linux using Mono."

This will be a big help

Currently working on a C# implementation of a web based in house CRM system.

Going to be nice to finally be able to support our Linux desktops as well.

We'll see how porting goes and if it's really worth the trouble.

Re:This will be a big help

Where did he say that cross-platform support was required? There's a big difference between something that's required and something that's nice.

Re:This will be a big help

"Particularly one that's practically indistinguishable from Java, which runs perfectly on both Windows and Linux by design."

Except that Java doesn't run perfectly on Windows and Linux. Many people see C# as a language that set out to be a better Java than Java, and many people feel that on the Windows platform it succeeds. Combine that with the existing Windows install base and you have a pretty compelling reason to develop in C# over Java.

Ten years down the line, however, I could see C# facing extinction if it does not become truly cross platform.

Re:This will be a big help

Particularly one that's practically indistinguishable from Java

Knock knock.

Who's there?

...long pause...

Java.

The only reason, ONLY reason, to use Java is because you are psychotic and have a deep, long standing hate for your users and wish to inflict some of the most insidious pain and torment upon them.

But can I actually use it for anything?

..and still nothing on whether WinForms is legally safe to use.

Re:But can I actually use it for anything?

"Worse, call the layers"

Which layer? does Mono have a self-destruct layer?

using System.Microsoft.Infringement;

public static void Main(string[] args)
{
      If (Patents.Count > 0)
      {
            ForEach(Match match in Patents
            {
                  Console.WriteLine(match.patentname + ": " + match.patentcode);
            }
      }
}

Error Buffer Overflow

Yeah, yeah... you meant "lawyers" I know... and I dont code in C# so it might not do anything anyways...but... "call the layers" made me laugh...

"This announcement has been long awaited ...

...by any .NET WinForms developer who has ever tried to get an applications to work on Linux using Mono."

All five of them.

Re:"This announcement has been long awaited ...

Five? I think you should stop rounding up to a whole hand!

Very nice

> I use .NET all the time, but I can't say I like it half as much as Python.

I know what you mean -- ELF just doesn't hold a candle to Perl.

SWF GUI builder?

Does this mean we can finally get a SWF GUI builder in MonoDevelop on Linux?

I've got a couple of apps I wrote while I was using Windows and now I use Fedora Linux. The back-end library code and my newer apps that use GTK# are fine to edit in MonoDevelop, but I've got a VirtualBox install with WinXP and Visual Studio in it for now so that I can update the System.Windows.Forms layouts when I need to.

Hopefully the "API complete" also means they'll fix some of the odd rendering I've seen at times :)

But why the Win32 style in WinForms?

From the blog:

You can use handles in Winforms, they just do not map to an actual HWND on non-Win32 systems, but you can definitely use them, and you can even override WndProc methods on derived classes from Control and process a pile of WM_ messages that Mono's Winforms actually builds on.

Why WndProc, HWND and WM_ messages are still there? I understand Microsoft built a software monopoly by mixing Window System management and a GUI toolkit together (and transferring it to .NET ensures that monopoly), but isn't .NET supposed to be one of the most advanced toolkits out there? Having to rely on WndProc, HWND and WM_ messages seems a very bad design for me (I've been developing MFC apps for a decade now and I know of the numerous problems that might come up), and unfortunately Mono WinForms copied that in order to be compatible with .NET.

Initially I thought 'wow, a contender to Qt/Java for building cross-platform apps', but after reading the blog and being an supporter of anything but Win32 (the ugliest API ever written), I will think twice before using Mono or .NET for cross platform development.

Re:But why the Win32 style in WinForms?

Use GTK# if you want a cross-platform UI toolkit based on .NET.

This work on WinForms is intended to provide a way to run .NET applications written for Windows on top of Mono. And for doing that, it has to be compatible with the Microsoft implementation of WinForms.

Re:But why the Win32 style in WinForms?

unfortunately Mono WinForms copied that in order to be compatible with .NET.

Um, yes, Windows compatibility was kind of the entire point of supporting Winforms, you know?

If you don't want to be compatible with Win32, use GTK#.

Re:too little, too late?

I'm also very interested to hear what these platforms are.

Re:too little, too late?

It is interesting that now that Mono is getting to a more complete (and possibly usable state), most developers have moved beyond the .NET hype and onto more elegant development platforms...

Please stop conflating Mono and .NET. Mono supports .NET, but that's not its primary API.

In fact, the primary API is the same API lots of open source software uses: Gnome, Gtk+, and many standard open source libraries. All Gnome apps using Mono use the Gtk+ APIs.

I wish there were better alternatives, but C# + Gtk# + MonoDevelop is probably the most elegant development platform right now. Nothing else really comes close. Python is a more elegant language but doesn't have a comparable IDE. Objective-C and Cocoa are messily intertwined with C and C APIs. And Java is a bloated pig.

Re:

Maybe the mono devs can get an implementation of IronPython going? Then you can have Python + a damn good IDE (i was surprised how well Mono Develop is myself)

Re:too little, too late?

IronPython already works fine on Mono, but it doesn't have IDE support. PyDev in Eclipse is pretty nice for pure Python and Jython.

Personally I'd rather work directly in Python/Ruby on GTK/Qt than go through an extra layer that is .NET. Maybe Anjuta could stop sucking and support Python, or Eclipse could have Glade integration.

And while Mono's not horrible, but it's not nearly as fast as the Sun JVM, so if I want fast bytecode I'd rather use Java than C#.

Re:too little, too late?

It's a pretty thin layer compared to an entire extra base library + bytecode runtime + OS abstraction.

PyGTK layers:

Your code (python)
PyGTK code (python)
Python runtime (C)
PyGTK->GTK binding (C)
GTK+libc code (C)
kernel (C)

IronPython + Gtk# layers:

Your code (python)
IronPython code (python)
IronPython runtime (CLI)
Gtk# code (CLI)
Mono base (CLI)
Mono runtime (C)
Gtk# -> GTK binding (C)
GTK+libc code (C)
kernel (C)

That's a fun one to deploy, let me tell you.

Re:too little, too late?

Java is fast? Go try to run Azureus and weep.

Oh, you do? And you think it is fast? Try utorrent on Windows or Transmission on OSX or KTorrent on Linux some time.

People can write slow programs in any language. The question is, can moderately competent programmers write fast, efficient, maintainable programs in them? Pointing to one example is pointless. Back on topic, a quick check on Alioth [debian.org] will show you that overall, Java is faster than C#/Mono but uses more memory (although on some benchmarks the opposite is the case). It's also worth pointing out that although Java is not faster than C++ on any benchmark, it's substantially slower on only three. In general the performance of a program has much more to do with good design and good algorithms than it has to do with choice of language.

Re:

Okay.

"Java might be a great development platform, but the performance of java apps on the desktop is so pitiful they're painful to use."

More?

"Sever-side apps written in Java have great perfs, however, which is easily explained since they're meant to be run

Re:

Say what you will about Mono, I think Microsoft's implementation of .NET is actually a pretty strong contender. If you need to solve a problem in Windows really fast, it can be pretty insanely convenient. I think Powershell in Windows Server basically uses

Re:Would be awesome...

Info for you: .NET 3.0 is 4 additional dlls, otherwise it IS .NET 2.0. Same runtime/etc. It adds:

-WCF: GREAT new tech. You write a module, and then expose it remotely via config. So if you want to change from Remoting to Compliant Web Services you simply change a config setting. Or you can expose simple services via REST. It abstracts "transport" from "functionality".
-Cardspace: dud. Single sign on/identity mgmt which is being replaced by openID it seems. Cool idea though.
-WPF: Cool new xml based description language to fully abstract process from gui much in the way ASP.NET does. It also lets UI designers "skin" apps seperately from the app code itself. VERY nice tech, especially the bindings.
-WF: Nice tech, not quite mature but neat to use. It allows for program logic to be described in an xml format (XAML) and shown in a gui designer. I really like workflow tech NOT because it lets business users program (it DOESN'T) but because it gives you an artifact that users can understand AND CONFIRM. .NET 3.5 is enhancements and bugfixes of 3.0 PLUS LINQ. LINQ is either the best thing ever, or the worst thing ever, depending on who you ask. I think "both." LINQ allows you to apply "sql-esque" syntax to any IEnumerable provider. So if you have an in memory collection of animals you can do:

var monkeys = from animal in myAnimalsCollection
                              where animal.Type == monkey
                              select new {animal.ID, animal.Name, animal.BirthDay};

foreach(var monkey in monkeys) .... do stuff

Re:Would be awesome...

LINQ is nice, except it's decades too late. Of the languages in common use today, Python and Ruby have much better alternatives to linq built in (and have had them for many years), and even new languages like Scala support similar functionality.

Your example in Python with a list comprehension, broken down into multiple lines for clarity:

monkeys = [
    (animal.id, animal.name, animal.birthDay)
    for animal in myAnimalsCollection
    if animal.type is monkey
]

And a comprehension of multiple lists is similar:

pairs = [
    (a, b)
    for a in range(10)
    for b in range(10)
    if b == a * 2
]

You have been able to do that for many years in Python, and yet Microsoft fanatics act like it's something new and innovative.

Re:Would be awesome...

The python version reads from an iterable, so it can be a request from a DB or an XML file sending its result one by one. In the case of the Db, the filtering will however be done by python and not in the DB.

However, there are alternative ORM python syntax to DB mappings, such as django syntax

AnimalCollection.filter(type='monkey')[:10].order_by('age')
(talking about simple orms, not full sqlalchemy table declaraions)

Being able to customize filtering of container classes for iterators definition would be cool anyway.

Re:Would be awesome...

You can use the same LINQ syntax to deal with data from all kind of data sources, that's what it is all about.

All the usernames on a Unix system:

print [line.split(':')[0] for line in file('/etc/passwd')]

Dates from an SQL table:

sth.execute('select invdte from invoice where invid=%(invid)s', {'invid': 1000090340})
print [row[0] for row in sth]

Search Google for "list comprehensions" and print the text of every "<a href" tag on the page:

import urllib2
import BeautifulSoup

agent = 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)'
url = 'http://www.google.com/search?q=list+comprehensions'
google = urllib2.Request(url, headers={'User-Agent': agent})
soup = BeautifulSoup.BeautifulSoup(urllib2.urlopen(google).read())
print [link.contents for link in soup.findAll('a')]

Basically, anything Python can loop across works inside a list comprehension. It's a basic construct of the language.