From the release announcement: “Almost a year ago we started building a set of Mono bindings for building native MacOS X applications. Our original goals were modest: bind enough of AppKit that you could build native desktop applications for OSX using C# or your favorite .NET language. We leveraged a lot of the code that we built for MonoTouch our binding to the CocoaTouch APIs.”
Am I the only Mac developer who’s never really done any C#/.NET who stills finds this very interesting?
I find the C# language quite nice after playing it for a few days, I’m almost sorry to say but it kinda feels like a real language compared to ObjC: good garbage collection, type safe, strong typing, LINQ, lambdas and more. And having the freedom to use the same APIs from other languages like F#, IronRuby, IronPython, etc is going to be awesome as well.
You don’t need IronPython. Regular Python runs fine on OS X.
Yes but, as I understand it, having all languages run on top of Mono(.NET / CLR(Common Language Runtime)) platform means if you write framework in C# for example its automatically available from from other .NET compatible languages, without having to write any bindings.
Second that, C# is a VERY NICE language, and I am a Mac Head.
Only problem with .net is Windows
Anyway, I really hope this takes off. I really like Cocoa, obj-c is nice, but nowhere near as nice as C#
I may not care too much for Microsoft as a company nor for their OS, but at least they learn from disasters like MFC/C++ and develop something great like C#.
Actually C# glory goes to Anders Heljsberg, .NET and C# architect and to Miguel de Icaza and their crews because their amazing job.
Glory also goes to Java – C# is basically (and purposefully) Java with a bunch of extra features, to ensure skillset is directly transferrable.
Thats like saying “a genius is a retard with a bunch of extra features”.
While they were mostly similar back in year 2000 now they are totally different languages with a common root.
So what’s this ultra-special stuff that makes it totally different? Lambdas? LINQ?
Having jumped back and forth between java and C# in my career for years at a time. I can name a few strong differences.
– Generic implementation are very different between the two. I could get into details but google can come up with many better examples that I can add in this comment.
– Anonymous classes in java versus functions as objects in C#. This difference gives you a very different codebase if you practice functional programming. Especially when combined with lambda’s you end up with api’s that do not resemble one another at all, and do not translate well. Having tried to make a type of LINQ in java, I can tell you it was unwieldy in that world.
– the Date/Time implementations are jarringly different if you used one and then the other.
– Assembly/Jar and versioning are also a bit of a shock. Vanilla Java doesn’t have the concept of versions and “jars” are just zip files with .class files in them. This gives you flexibility and some annoying limitations at the same time when dynamically loading code at runtime. Both languages have their sucky parts here but neither really resemble one another too well.
Indeed. C# is the only thing from Microsoft that I truly think is superlative.
Microsoft basically killed Iron*, and F# is irrelevant.
C# is the only .net language with any real future.
How is F# irrelevant?
F# is now available under a viable (and from what I understand, GPL compatible) open source license.
F# is a functional language which for us computational physics folks is incredibly useful.
Even if it is not extremely popular for ‘business’ programming, who cares? thats the beauty of .net: everything compiles to assemblies which are callable from any other .net language. .Net is fairly close to language independent programming.
I’m glad to hear that.
I too find this very interesting since I plan on adapting Mono in order to bring my music application to the Mac and Linux platform. My main goal with the application was to make it look really native and consistent. So it will be very fun to do this on the Mac as well.
I really hope that it allows developers to create applications that look like they are the default Mac application, a part of the rest of the system. I don’t want users to be able to know if the application is based on Mono or native.
Mono applications ARE native provided they use Cocoa. The language does not matter, all of compiles to similar machine code, all that maters is what UI toolkit it uses.
When you use something like QT/GTK you are using the toolkits rendering and layout system, basically the toolkit renders its own widgets to a bitmap, then eventually draws the contents to the screen. On OSX, QT tries to fake out the native widgets, but it does a pretty piss poor job.
Now, what would be really really cool is if someone (with more time than me) would build Mono’s WinForms on top of MacMono’s Cocoa bindings. Now, that would make for a killer cross platform UI library.
Edited 2011-03-20 00:35 UTC
Sorry if I confused you but when I wrote “native” I meant that as seen by the user, that is: how it looks and behave relative to the operating system. I know that the code is compiled into native machine code.
What I meant was “given Mono, how close can you get to being felt like a ‘default’ program?” or maybe put differently “how much of the Cocoa API is supported through MonoMac?”.
I do know that a lot of toolkits try to look native but they just don’t cut it. I really think that it is important to integrate well with the operating system. Jumplists on Windows 7, spell-checking and keyring on Mac, etc etc etc.
Edited 2011-03-20 01:30 UTC
As far as I can tell they look exactly like normal Cocoa apps, as you actually use Interface Builder for the UI design, and can subclass NSView (or derivatives) for custom drawing the same way you can in ObjC.
I think most APIs are done as well, there is a status page here: http://www.mono-project.com/MonoMac#Status
And if you really need to its very easy (compared to JNI etc) to call C code from C#, an example: calling ‘puts’ from C# on OSX: http://pastebin.com/84y6YByv
Edited 2011-03-20 11:32 UTC
hallelujah, someone actually thinks apps should take advantage of native OS features, AMAZING!
Beware the flaming wrath of the lazy “cross platform UI” developers who thinks otherwise.
You are wrong, Qt uses Cocoa APIs to render their widgets; so, in fact, Qt does not fake out the native widgets on the Mac, but it delegates Cocoa to paint them.
Looked at the QT source? QT does fake out widgets. Basically what it does is use Cocoa to create a window. Then it uses a QT theme to draw the widgets. One of the themes is the Mac theme, this theme uses some OSX toolbox functions to draw some parts of a widget to a pixmap. Then QT does all its own drawing to this pixmap, eventually all the widget pixmaps are drawn to a window pixmap, then finally there is a single Cocoa call that actually draws this pixmap to the screen.
Thats why you can have a QT app use any theme it wants on OSX.
When I use a QT app on OSX, I do not use the Mac theme because it is pretty bad: things don’t line up, everything is just a little bit off, font rendering is strange, so forth.
Furthermore, QT is a ‘least common denominator’ toolkit, you can not use things that are unique to the OS you’re targeting. You can not use any of the great new UI features in Win7 or OSX.
This is why I’m excited about macmono, because C# is a great language to work in, and MonoMac now has essentially complete bindings to the native UI toolkit.
Edited 2011-03-20 13:39 UTC