> 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
