There is one C# GUI Framework that you missed for OS X: Dumbarton, used by imeem.com. It allows you to create your GUI with the normal Apple tools and resources such as .nib files, while using C# code to respond to the GUI events:

http://www.imeem.com/developers.aspx

http://allan.imeem.com/blogentry/gbgC7kTg

There is also an effort to port GTK+ to use Cocoa, so all Gtk# apps should be usable without the X11 server running in the future. The real question is _when_ this will happen, but alas I have no idea:

http://developer.imendio.com/projects/gtk-macosx

Hi Jonathan - and thanks for the comments.

I was aware of the effort to port GTK+ to Cocoa, hence my reference to a Core Graphics version of System.Drawing.dll being "in the pipeline". But as you say, the real question is when !!!

As regards Dumbarton, I was unaware of this. Many thanks for the heads-up: I will check it out.

Uncle Mac

The article misses the point in a couple of ways:

"The real stomping ground of Mono is undoubtedly Linux" Actually, it's open systems. You noticed that on Mac it works fine with all the standard, open APIs (meaning most non-GUI functions, plus GUIs under X) but not with the proprietary and Mac-specific Cocoa. You then derail completely: "any efforts expended in terms of building a more feature-complete implementation of Cocoa# would, in a sense, be wasted effort from a portability point of view since Cocoa" well, no, it wouldn't be wasted, because then Mac users would be happy to run Mono GUI apps, and you've already correctly observed that they won't run apps that don't look native. And "What’s the point in writing your application using an ECMA certified, platform-neutral language when all you’re doing is making calls to a proprietary, platform-specific toolkit?" okay, so let's give up writing in C, because all we'm doing is generating proprietary, plaform-specific instructions. Seriously, this is a major part of the point of Mono: you can write one app, and it will run on Windows (where it is simply calling proprietary, platform-specific APIs) or Linux (where it is calling platform-specific APIs that may be open, but certainly aren't as neatly standardised as Mono's), or whatever other system you're on.

And then this: "I expect some pundit will be along soon to assure me that if I just added a couple of lines of gobbledegook to this config file". Why didn't you ask whether Apple could make X work decently? A rootless X server that starts automatically when required would remove all the objections to running X apps under Aqua except for the "look-and-feel" one, which for many programs is enough.

Finally, to describe Cocoa as proprietary is not entirely fair, and you didn't mention the obvious riposte of the Mac-centric open source development, namely to use GNUStep. Read this article, for example:

http://www.macobserver.com/columns/devilsadvocate/2003/20030606.shtml

Finally, your conclusion: "in terms of how/where they fit into Mac development, I think it’s time to step back and re-evaluate where we’re going." is nonsense. It fits in just like it does on any other desktop platform, and it's obvious where we're going: eventually, Mono will work fine on Mac OS. What seems to be lacking is sustained effort in that direction. All that's needed to get there quicker is more effort. Apple could help if they wanted, and, as for any minority platform, it would seem to be a big win: they're far more likely to attract than lose devotees by such a move. Equally, more Mac developers could get involved. Like most OSS projects, this one will stand or fall in the straightforward market-place of development investment, wherever it comes from.

I would like to offer a reverse perspective. I am a .Net developer, I have many apps that I need to develop and maintain all using the .net framework.

Now, if I want to be able to use a beautiful machine with a decent operating system - namely a MAC - and still develop the .Net applications I am already maintaining, then I have a chance of doing at least some of my development work natively on a Mac using Eclipse instead of being stuck using something like BootCamp or Parallels all the time. So Mono and GTK for Cocoa are all good things... Please just give me a reason to switch to a Mac!

Also, you missed the point that a LOT of .net development is in the space of server side / web applications. Currently there are two approaches to making a .net app portable to an XServe or Unix server - either use Mono or Grasshopper.

Mono for web apps is a real and viable alternative to being stuck on Wintel servers using IIS. In fact that was the focus of compatibility efforts in the early days of Mono if I am not mistaken.

Grasshopper from Mainsoft is the alternative to Mono for the server side; it is a completely different approach and essentially turns .net apps in to J2EE apps through the compilation process. This technology is aimed SQUARELY at server side development.

Either approach opens the path for hardware and OS platform independence whilst still using a great language and development platform.

Conclusion: Especially if you have an investment in skills or IP this is a path which can easily and effectively help free you from being chained to a specific hardware or OS vendor.

Hi Reuben and thanks for the comments. You said:

> You noticed that on Mac it works fine with all the

> standard, open APIs (meaning most non-GUI functions,

> plus GUIs under X) but not with the proprietary and

> Mac-specific Cocoa. You then derail completely:

> "any efforts expended in terms of building a more

> feature-complete implementation of Cocoa# would,

> in a sense, be wasted effort from a portability

> point of view since Cocoa" well, no, it wouldn't be

> wasted, because then Mac users would be happy to

> run Mono GUI apps,

Unfortunately, that's by no means certain. As I said in the article, a key factor holding back Mono on the Mac is the lack of support for Cocoa. However, even if Cocoa *WAS* seamlessly supported, Mac users would also want the ability to just drag an application bundle off a distribution CD and plonk it into their /Applications folder. I'm a little dubious about whether we're ever going to get to this stage with Mono. Another reader has emailed me the following perspective:

"Mono is a very complex, nay, fraught, system. Mono is far more difficult and complex to set up than even the Gnome/glib/glib*/gtk*/g* suite of libraries and dependency files. If it ever achieves significant penetration in the UNIX sphere, not only will UNIX people be dealing with something vastly more complex than the combination of library version and LD_LIBRARY_PATH and PATH, but Microsoft will just change some subtle parameter and break compatibility. In any case Microsoft would drive UNIX's config qua Mono."

I've got some sympathy with that view. ;-)

You then say:

> and you've already correctly observed that they

> won't run apps that don't look native. And "What’s

> the point in writing your application using an ECMA

> certified, platform-neutral language when all

> you’re doing is making calls to a proprietary,

> platform-specific toolkit?" okay, so let's give up

> writing in C, because all we'm doing is generating

> proprietary, plaform-specific instructions.

> Seriously, this is a major part of the point of

> Mono: you can write one app, and it will run on

> Windows (where it is simply calling proprietary,

> platform-specific APIs) or Linux (where it is

> calling platform-specific APIs that may be open,

> but certainly aren't as neatly standardised

> as Mono's), or whatever other system you're on.

With respect, I think _you're_ missing the point here. Like I've said, existing Objective-C, Cocoa developers aren't going to want to give up their preferred language or preferred framework easily. Potentially, one big carrot for such developers would be the huge benefit of writing applications which could be easily ported to Windows. So they give up ObjC and start writing in C#. They end up with portable apps which look horrible on the Mac! Not acceptable! So they (hypothetically) start using Mono with Cocoa bindings. Now their apps look great on the Mac but won't port to Windows. Again - not acceptable! They may as well have stuck with the native tools in the first place.

> And then this: "I expect some pundit will be along

> soon to assure me that if I just added a couple

> of lines of gobbledegook to this config file". Why

> didn't you ask whether Apple could make X work

> decently? A rootless X server that starts

> automatically when required would remove all the

> objections to running X apps under Aqua except for

> the "look-and-feel" one, which for

> many programs is enough.

Sorry, but no. Look and feel is a major issue on the Mac - that's why people use Macs. :-) Even if the X server could be made to start automatically when required, the resulting applications would still look awful compared to native stuff. They simply would not be acceptable - trust me on this. How many people are marketing applications for XP (Vista even) that look as if they've just escaped from Windows 95? Answer: not many! Rather than asking Apple to fix the X server, why not ask yourself why it is that Qt (Trolltech) seem able to produce great looking portable applications that work on Windows, Linux, etc, and don't need X on the Mac?

> Finally, to describe Cocoa as proprietary is not

> entirely fair, and you didn't mention the obvious

> riposte of the Mac-centric open source development,

> namely to use GNUStep. Read this article,

> for example:

I think it is perfectly fair to describe Cocoa as proprietary - what makes you think it isn't propretary? I'm aware of GNUStep, but doesn't this add more deployment complications on the Win32 platform? For me, Cocoa isn't the key issue: the key issue is getting something that looks good on all supported platforms. Qt seem able to achieve it, even small outfits like wxWidgets achieve it - both with and without X. Why not Mono?

> and it's obvious where we're going: eventually,

> Mono will work fine on Mac OS.

Absolutely - and eventually we'll achieve world peace, but back in the real world developers need to make strategic decisions now.

> What seems to be lacking is sustained effort in that

> direction. All that's needed to get there quicker

> is more effort.

Can't disagree with that. ;-)

Uncle Mac