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

[Jonathan LaCour]

Steve, Greg, and List,

After some additional research into the issues involved, I believe that
Stevešs summary is quite accurate.  My personal conclusion is that we should
give Windows.Forms our best shot using straight Cocoa/Quartz first, and use
Carbon as a fall-back option.  Clearly we have hashed out many of the
advantages and disadvantages of both, and we can make a well-informed
decision when the time comes.

I also recently read that much of the Carbon complaints that I currently
have are being addressed in OS X 10.2 (improved font anti-aliasing, more
OSX-like behavior, elimination of a few OS 9ish oddities).  This is of
course good news for all.

For my part, I know a good bit about Cocoa already, but have just placed
orders on a few Cocoa books and a few Carbon books that I have not yet read.
I will continue to research and when Mono is ready for Windows.Forms, I will
hopefully be ready to help too.  Although, I will need to do some research
about Windows.Forms to really know what I am getting into.  Any ideas where
I could start?

 - Jonathan

> 
> From: Steve Newman <steve@snewman.net>
> Date: Tue, 16 Apr 2002 15:25:19 -0700
> 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
>