[prev in list] [next in list] [prev in thread] [next in thread]
List: mono-osx
Subject: Re: [Mono-osx] Mono 2.6 and Windows.Forms on MacOSX
From: Duane Wandless <duane () wandless ! net>
Date: 2009-12-31 20:43:54
Message-ID: d57001c10912311243q5358655cja7ef54142abf2114 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-osx
>
[Attachment #5 (text/html)]
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.<div> <br></div><div>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. </div> <div><br></div><div>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.</div> \
<div><br></div><div>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.</div><div><br></div><div>Duane<br> <br><div \
class="gmail_quote">On Thu, Dec 31, 2009 at 3:23 PM, Lee V. Andrus <span \
dir="ltr"><<a href="mailto:landrus2@by-rite.net">landrus2@by-rite.net</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <br>
<br>
Andrew Brehm wrote:<br>
><br>
> ...<br>
<div class="im">> (You need a name for your project!)<br>
</div>> ...<br>
<div class="im">> IDEALLY we would need one project consisting of DLLs that allow \
native use<br> > of Cocoa classes and methods as well as a Windows.Forms \
compatibility<br> > wrapper. And the recommended way for .NET applications on Mac \
OS X would<br> > then be to use Windows.Forms and the wrapper and direct Cocoa \
classes only<br> > for some effects.<br>
</div>> ....<br>
><br>
I have floated the name "Cocoa Conspiracy" in this forum, but no one \
was<br> interested in conspiring with me. My project is implementing<br>
System.Windows.Forms.XplatUICocoa, the Cocoa Driver for Mono's MWF. This is<br>
the heart of the implementation of MWF. It is not a bridge or thin wrapper<br>
like the products we discussed. It currently uses MObjc and MCocoa to<br>
facilitate access to the Cocoa framework. All the other implementations of<br>
XplatUIDriver just use PInvokes to access the underlying window system APIs,<br>
but they all are based on simple C functions calls. Marshaling Mono<br>
subclasses of the Cocoa framework classes across the divide is a big help.<br>
<br>
The project's aim is to help the portability of .Net/Mono applications the<br>
Mac. Some insist you cannot get a really good UI without customizing it for<br>
each platform. But I believe that the ability to take an executable from<br>
one platform to another, and get reasonably correct behavior and appearance<br>
is achievable and will give a huge boost to cross-platform interoperability.<br>
There are other cross-platform GUIs (like GTK#) out there, but I suspect<br>
that the people using them are outnumbered by .Net developers using SWF.<br>
SWF is key to making the Mac accessible to the .Net talent pool. The Carbon<br>
Driver is riddled with calls to functions that have been deprecated or are<br>
not available to 64-bit applications. Apple introduced Carbon to ease the<br>
transition from OS 9 to OS X and seems more inclined to retire it than to<br>
maintain it.<br>
<font color="#888888">--<br>
View this message in context: <a \
href="http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26981940.html" \
target="_blank">http://old.nabble.com/Mono-2.6-and-Windows.Forms-on-MacOSX-tp24047606p26981940.html</a><br>
</font><div><div></div><div class="h5">Sent from the Mono - OSX mailing list archive \
at Nabble.com.<br> <br>
_______________________________________________<br>
Mono-osx mailing list<br>
<a href="mailto:Mono-osx@lists.ximian.com">Mono-osx@lists.ximian.com</a><br>
<a href="http://lists.ximian.com/mailman/listinfo/mono-osx" \
target="_blank">http://lists.ximian.com/mailman/listinfo/mono-osx</a><br> \
</div></div></blockquote></div><br></div>
_______________________________________________
Mono-osx mailing list
Mono-osx@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-osx
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic