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
Back to the article
