[Mono-list] Windows.Forms on OSX

[Greg Brown]

"...remember that Objective-C is simply a superset of ANSI C.  This means
that you could easily write a standard C program and compile it with an
Objective-C compiler.  With this in mind, I do not think that this would be
too large of a barrier to the Windows.Forms implementation."

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.

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:

- object wrappers (or "helpers") for basic programmatic types and
operations,
including strings, arrays, dictionaries, numbers, byte swapping, parsing,
and
exception handling
- object wrappers for kernel-environment entities and services, such as
tasks,
ports, run loops, timers, threads, and locks
- object-related functionality, particularly memory management (autorelease
pools), remote invocations, archiving, and serialization
- file-system and I/O functionality including URL handling, file seeking,
and
dynamic loading of code and localized resources
- other services, such as distributed notifications, undo (and redo), data
formatting, and dates and times

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. 

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.

G

-----Original Message-----
From: Jonathan LaCour [mailto:panix-lists@skinnee.net]
Sent: Tuesday, April 16, 2002 1:49 PM
To: mono-list
Subject: Re: [Mono-list] Windows.Forms on OSX


I completely disagree with Greg here.  Cocoa is really the wave of the
future for development in Mac OS X and it would be short-sighted to port to
Carbon over Cocoa unless its absolutely necessary.

First of all, I have noticed that Cocoa applications behave and look
consistently and noticeably better than Carbon applications.  I have noticed
this throughout MS Office v.X, and in many places it makes the applications
look unprofessional.  I would hate for this to transition over to Mono's
Windows.Forms implementation.

In addition, Carbon was originally intended as a bridge between OS 9 and OS
X.  It has since evolved into a more robust framework that entirely new
applications can be written for, but Cocoa is still the framework of choice
for Apple.  Carbon is generally used to port applications from OS 9 to OS X,
because it minimizes the porting necessary, while still allowing the
application to run natively on OS X.  This is true for many applications
currently, including MS Office v.X, Adobe Photoshop, and many other
mainstream applications.

Mono on the other hand is a new project that has never existed on OS 9.
Thus, if effort is going to be put into the Windows.Forms portion of .NET, I
would much prefer and encourage it to be done on the Cocoa framework.  It
simply makes more sense.  I am not sure if it would take more time using
Cocoa, but doing it right is more important than doing it quickly --
especially in free software.



Just my two cents =)

 - Jonathan

> From: Greg Brown <gbrown@molecular.com>
> Date: Tue, 16 Apr 2002 11:28:02 -0400
> To: "Mono List (E-mail)" <mono-list@ximian.com>
> Subject: [Mono-list] Windows.Forms on OSX
> 
> Hi,
> 
> I'm a new subscriber to the list. I was excited to read recently that
Ximian
> is planning to bring Mono to Mac OSX.
> 
> I noticed on the Mono project site that the plan is to implement
> Windows.Forms on OSX using the Cocoa framework. I don't know how far along
> the port is, but I'm curious to know if anyone has looked into the
> feasibility of using Carbon as opposed to Cocoa. From what I understand,
the
> team currently porting the SWT (a Java GUI API that is part of the Eclipse
> project, http://eclipse.org) to OSX chose Carbon over Cocoa because Carbon
> is a lower-level API. Among other things, I know they had a lot of trouble
> mapping SWT's event model to Cocoa. Although I have not yet used it, I
> imagine that the Windows.Forms event model is similar, since I understand
> that it provides low-level access to the system event loop. There were
also
> some other issues. A port of Windows.Forms to OSX using Cocoa could face
> similar challenges.
> 
> Additionally, Cocoa applications are written either in Objective-C or in
> Java. I don't believe Cocoa is accessible from C. This may or may not be
an
> issue for Mono - not having seen any of the source code yet, I don't know
> how it is being implemented under the hood.
> 
> So, it seems like it might be worth considering using Carbon. Thoughts?
> 
> Greg
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 


_______________________________________________
Mono-list maillist  -  Mono-list@ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list