> 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 =)

Cocoa is probably easier to hook up to--because of the reflection capabilities
found in Objective-C, it is very easy to access any Cocoa object without
writing a lot of glue code.   Look at the Python or Lua bindings for Cocoa,
for example.

I'm not sure that's worth it, though.  I don't see either Carbon or
Cocoa remaining the APIs of choice for implementing new Mac applications
in a few years.

Maybe a better choice would be to either just use a native port of Gtk+
or to just write a new toolkit in C# itself.   I think either of those
efforts would be more useful to more people.

Tom.


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

_______________________________________________
Mono-list maillist  -  [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list

Reply via email to