[Mono-osx] Mono 2.6 and Windows.Forms on MacOSX

[Duane Wandless]

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 and
on Mac.

Many similarities exist in a UI but it is the details that make an app feel
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 apps
are rendered.  They are using the native tools which provides an accurate UI
for the end user.

Duane

On Thu, Dec 31, 2009 at 3:23 PM, Lee V. Andrus <landrus2 at by-rite.net> wrote:

>
>
> Andrew Brehm wrote:
> >
> > ...
> > (You need a name for your project!)
> > ...
> > IDEALLY we would need one project consisting of DLLs that allow native
> use
> > of Cocoa classes and methods as well as a Windows.Forms compatibility
> > wrapper. And the recommended way for .NET applications on Mac OS X would
> > then be to use Windows.Forms and the wrapper and direct Cocoa classes
> only
> > 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
> is
> the heart of the implementation of MWF.  It is not a bridge or thin wrapper
> like the products we discussed.  It currently uses MObjc and MCocoa to
> facilitate access to the Cocoa framework.  All the other implementations of
> XplatUIDriver just use PInvokes to access the underlying window system
> APIs,
> but they all are based on simple C functions calls.  Marshaling Mono
> subclasses of the Cocoa framework classes across the divide is a big help.
>
> The project's aim is to help the portability of .Net/Mono applications the
> Mac.  Some insist you cannot get a really good UI without customizing it
> for
> each platform.  But I believe that the ability to take an executable from
> one platform to another, and get reasonably correct behavior and appearance
> is achievable and will give a huge boost to cross-platform
> interoperability.
> 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
> Carbon
> Driver is riddled with calls to functions that have been deprecated or are
> not available to 64-bit applications.  Apple introduced Carbon to ease the
> transition from OS 9 to OS X and seems more inclined to retire it than to
> maintain it.
> --
> View this message in context:
> http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26981940.html
> Sent from the Mono - OSX mailing list archive at Nabble.com.
>
> _______________________________________________
> Mono-osx mailing list
> Mono-osx at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-osx/attachments/20091231/1c2f9acf/attachment.html