[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX
ajbrehm at gmail.com
Thu Dec 31 22:20:03 EST 2009
Which brings us to option 3, which I am most fond of: support both
Wrap whatever is possible in Cocoa in Windows.Forms and allow direct access
to native objects for what remains.
A Windows.Forms binary should run unmodified on Mac OS X and look native.
But it should also be possible for .NET programs to use features of Cocoa
that are not (and cannot be) represented by the Windows.Forms wrapper around
I think both are important.
But this requires consolidation of the projects or at least some
organisation. Which brings us back to my original point. :-(
> After extensive research in how best to bring our C# application from
> Windows to Mac we deemed the only viable solution was to write the UI in
> native Cocoa. The UI embeds Mono and using mobjc/mcocoa the C# classes
> expose the core business logic. Yes some code is written twice. This
> overhead is well worth the cost of having a native looking UI on Windows
> on Mac.
> Many similarities exist in a UI but it is the details that make an app
> natural. Given that most Mac users are fanatics, especially in our user
> base, having a sub-standard UI was not an option.
> The theory of reusing a Windows Form application out of the box sounds
> good... however in practice the end result will not behave like a 100%
> native Mac application. That is not an acceptable option in my mind.
> It is the same concept for MonoTouch. They did not reinvent how iPhone
> are rendered. They are using the native tools which provides an accurate
> for the end user.
> On Thu, Dec 31, 2009 at 3:23 PM, Lee V. Andrus <landrus2 at by-rite.net>
>> Andrew Brehm wrote:
>> > ...
>> > (You need a name for your project!)
>> > ...
>> > IDEALLY we would need one project consisting of DLLs that allow native
>> > of Cocoa classes and methods as well as a Windows.Forms compatibility
>> > wrapper. And the recommended way for .NET applications on Mac OS X
>> > then be to use Windows.Forms and the wrapper and direct Cocoa classes
>> > for some effects.
>> > ....
>> I have floated the name "Cocoa Conspiracy" in this forum, but no one was
>> interested in conspiring with me. My project is implementing
>> System.Windows.Forms.XplatUICocoa, the Cocoa Driver for Mono's MWF. This
>> the heart of the implementation of MWF. It is not a bridge or thin
>> like the products we discussed. It currently uses MObjc and MCocoa to
>> facilitate access to the Cocoa framework. All the other implementations
>> XplatUIDriver just use PInvokes to access the underlying window system
>> but they all are based on simple C functions calls. Marshaling Mono
>> subclasses of the Cocoa framework classes across the divide is a big
>> The project's aim is to help the portability of .Net/Mono applications
>> Mac. Some insist you cannot get a really good UI without customizing it
>> each platform. But I believe that the ability to take an executable from
>> one platform to another, and get reasonably correct behavior and
>> is achievable and will give a huge boost to cross-platform
>> There are other cross-platform GUIs (like GTK#) out there, but I suspect
>> that the people using them are outnumbered by .Net developers using SWF.
>> SWF is key to making the Mac accessible to the .Net talent pool. The
>> Driver is riddled with calls to functions that have been deprecated or
>> not available to 64-bit applications. Apple introduced Carbon to ease
>> transition from OS 9 to OS X and seems more inclined to retire it than to
>> maintain it.
>> View this message in context:
>> Sent from the Mono - OSX mailing list archive at Nabble.com.
>> Mono-osx mailing list
>> Mono-osx at lists.ximian.com
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
View this message in context: http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26983564.html
Sent from the Mono - OSX mailing list archive at Nabble.com.
More information about the Mono-osx