[Mono-list] Windows.Forms on OSX

[Jonathan LaCour]

> This is a valid point. I also just read that it is possible to invoke Carbon
> methods from within an Objective-C program. So, it is possible to go to the
> Carbon layer from Cocoa if necessary.

True, but I am not sure why you want to do this.  I think that you may be
confused a bit.  Cocoa and Carbon exist as separate alternative frameworks
on the same layer.  All of their drawing portions are implemented through
Quartz, which is Apple's 2-D drawing layer.  Much of the Windows.Forms work
will happen using Quartz anyway!

> However, from what I've read, it seems like .NET and Cocoa should actually
> exist in parallel. They are actually pretty similar in intent. Consider some
> of the services Cocoa provides, from the Mac OSX System Overview doc:

Well, of course they could exist in parallel =)  They are separate things.
In fact you are right in stating that they serve many of the same functions
-- which is exactly why we can map Windows.Forms constructs onto their
Cocoa/Quartz equivalents.

> These are all pretty high-level constructs that the CLR and the .NET
> framework also offer. There is a risk that Cocoa's abstractions may not map
> well to .NET's. e.g. Cocoa does something that made it difficult to
> implement the SWT event handling system on top of it. SWT's event handling
> maps almost one-to-one to the Windows event loop, which I'm sure
> Windows.Forms also uses. If it was difficult for the SWT team, it will
> probably be difficult here as well.

I understand your point here that the abstractions may not map directly very
well.  But this is a struggle any time that porting occurs.  In addition,
Carbon is for legacy code and I am afraid that it might not be supported in
the future.  Why go with the old API when developing something new?

> On Windows, .NET is implemented on top of the Win32 API. Similarly, I would
> guess that much of Cocoa is implemented on top of Carbon. I've read
> somewhere that there is nothing you can do in Cocoa that you can't do in
> Carbon. Cocoa just makes some tasks easier. It seems like it would be worth
> at least considering using Carbon to implement Windows.Forms, since
> Windows.Forms is a higher level abstraction, and you want as much
> flexibility from the lower layers as possible.

Cocoa is not implemented on top of Carbon.  Cocoa was implemented as a pure
Objective-C framework that uses Quartz for its 2-D drawing and windowing.  I
think that you need a better understanding of the Apple development
libraries.  I would suggest checking out the following URL that contains a
nice diagram that shows how everything breaks down simply:

    http://developer.apple.com/macosx/architecture/

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

 - Jonathan