[Mono-list] Re: Windows.Forms on OS X
Steve Newman
steve@snewman.net
Tue, 16 Apr 2002 15:25:19 -0700
--============_-1193126576==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 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
--============_-1193126576==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: Windows.Forms on OS X</title></head><body>
<div><font face="Courier New" color="#000000">> There you will see
that Carbon is really intended for</font></div>
<div><font face="Courier New" color="#000000">> porting legacy Mac
OS code, and is based on older API's.</font></div>
<div><font face="Courier New" color="#000000">> Cocoa is for new
code. Cocoa is a higher level framework,</font></div>
<div><font face="Courier New" color="#000000">> which heavily makes
use of Quartz for doing all low-level</font></div>
<div><font face="Courier New" color="#000000">> graphics
operations.</font></div>
<div><font face="Courier New" color="#000000">></font></div>
<div><font face="Courier New" color="#000000">> I digress... we
need to use Quartz and Cocoa to implement</font></div>
<div><font face="Courier New" color="#000000">> Windows.Forms, and
avoid Carbon at all costs, since its for</font></div>
<div><font face="Courier New" color="#000000">> legacy code anyway
=)</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">Here are the issues as I
see them:</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">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.</font></div>
<div><font face="Courier New" color="#000000"><br></font></div>
<div><font face="Courier New" color="#000000">-- Steve</font></div>
</body>
</html>
--============_-1193126576==_ma============--