[Mono-list] Re: Windows.Forms on OS X

[Greg Brown]

Steve-
Excellent summary of what I was trying to say. Thanks.  :-)
G

-----Original Message-----
From: Steve Newman [mailto:steve@snewman.net]
Sent: Tuesday, April 16, 2002 6:25 PM
To: mono-list@ximian.com
Subject: [Mono-list] Re: Windows.Forms on OS X


> There you will see that Carbon is really intended for
> porting legacy Mac OS code, and is based on older API's.
> Cocoa is for new code.  Cocoa is a higher level framework,
> which heavily makes use of Quartz for doing all low-level
> graphics operations.
>
> I digress... we need to use Quartz and Cocoa to implement
> Windows.Forms, and avoid Carbon at all costs, since its for
> legacy code anyway =)


It's true that Carbon was created for the benefit of legacy code, but I'm
not sure it should be dismissed it out of hand.  Carbon exists, it works,
and it's likely to be supported for a very long time (since many of the
major OS X applications are based on it).  So, if it's easier to write
Windows.Forms on top of Carbon than Cocoa, then Carbon may be the better
choice.


Here are the issues as I see them:


1. Cocoa is the older, more mature framework, and one gets the sense that
Apple "likes it better".  All other things being equal, Cocoa is probably
the framework of choice.  However, I think it's easy to overstate this.
Carbon is well supported, and (as noted above) is likely to remain so.


2. There is a general impression that Cocoa applications act "more native"
than Carbon applications, with better adherence to the Mac OS X UI
guidelines, better performance, etc.  However, I've never heard a solid
reason given for this.  I suspect that it's partly a false perception,
caused by the fact that most Cocoa applications were written with Mac OS X
in mind, while most Carbon applications are ports.  However, there may be
some truth here.


3. Carbon can be used in C++; Cocoa requires C (or Objective C).  This is
not a huge issue (it can be eliminated with glue code, and some people
prefer C anyway), but it's an issue.


4. There is an impression that Cocoa is "higher level" than Carbon, which
could be good (a more powerful toolkit) or bad (dictates too much behavior
to allow implementing Windows Forms correctly).  I don't know enough about
Cocoa to evaluate this, but it should be taken seriously.  I have experience
with emulating one application framework on top of another, and it can be
extremely difficult to do this well if the target framework is "too high
level".  It would be a real shame to go down the road of implementing
Windows.Forms on Cocoa and later discover that it can't be done well.


It would be very useful to "test the waters", by writing a simple Cocoa
application (in C, Objective C, or Java) that implements a subset of
Windows.Forms as an internal API.  Also, someone should talk to the Eclipse
team to find out specifically what problems they had porting SWT to Cocoa.


I don't claim to derive a conclusion from this, I'm just trying to lay out
the issues.  Is this list complete?  Is it correct?  If so, then we can
discuss the relative weight of each issue.  If not, please help me complete
it.


-- Steve