Interfaces de usuario de creación de cacao para OS X con C# y Mono

Question

¿Alguien ha pasado tiempo comparando los diversos puentes de Objective C y envolturas de cacao asociadas para Mono?

Quiero portar una aplicación C# existente para ejecutar en OS X. Lo ideal sería que ejecutara la aplicación en Mono, y construiría una UI de Cocoa nativa para ella.

Me pregunto qué puente sería la mejor opción.

En caso de que sea útil para cualquier persona, aquí hay algunos enlaces a los puentes que he encontrado hasta ahora:

• CocoSharp - distribuido con Mono en OS X - www.cocoa-sharp.com

• Monobjc - mejor documentación que los demás (en mi opinión) - www.mono-project.com/CocoaSharp y www.monobjc.net

• NObjective - (aparentemente) más rápido que los otros - code.google.com/p/nobjective

• MObjc/MCocoa - code.google.com/p/mobjc y code.google.com/p/mcocoa

• ObjC# - www.mono-project.com/ObjCSharp

Answer 1

El equipo Mono ha lanzado un nuevo puente llamado MonoMac.

Es esencialmente la versión de escritorio del marco MonoTouch que produjeron para el iPhone.

Miguel anunció el nuevo puente en su blog aquí: http://tirania.org/blog/archive/2010/Apr-19.html

Una vez MonoMac madura, sospecho que se convertirá en utilizan las personas puente.

Answer 2

No va a pregunte por qué, ya que tiene sus razones, estoy seguro.

Me gustaría ver el proyecto Unity3D y ver si se puede saber cómo lo hicieron. Parece, um, difícil.

Answer 3

Creo que NObjective es la mejor elección, ya que cuenta con generación automática de código para contenedores Objective-C que se pueden configurar fácilmente para regenerar envoltorios para futuras versiones de Mac OS.

Answer 4

Bien, voy a preguntar: ¿por qué querrías hacer esto? La arquitectura del UI de Cocoa, incluidas las delgadas Cocoa-std y los bindings de cacao, están estrechamente relacionadas con Objective-C. La combinación de Interface Builder y Objective-C es notablemente productiva. Aunque puede utilizar Interface Builder con muchos puentes hacia Objective-C (incluyendo PyObjC, MacRuby y muchos de los puentes C#), inevitablemente perderá productividad debido a cualquier impedancia no coincidente entre el marco y el idioma de su elección. Con C#, esta falta de coincidencia es significativa. Ya que está escribiendo una interfaz de usuario nativa, perdiendo así cualquier ventaja multiplataforma que obtendría de C#, usaría Objective-C. Para un competente C/C++/C#/Java/etc. programador, generalmente toma 2-3 días para sentirse cómodo y productivo en Objective-C.

Answer 5

He estado probando Monobjc, NObjective y MObjc/MCocoa con F # últimamente y voy a ir con MObjc/MCocoa.

Monobjc es como usted escribe mejor documentado y empaquetado, pero en comparación con los otros dos muy slow y no "replantea excepciones" de ObjC.

Creo que NObjective y MObjc/MCocoa son los únicos que vuelven a lanzar excepciones de ObjC y es por eso que considero que son las únicas alternativas reales.

Como se discutió here NObjective utiliza structs con herencia que encuentro bastante aterrador y finalmente me hizo elegir MObjC/MCocoa.

(Es posible que haya un problema de licencia también. Monobjc y NObjective está bajo LGPL, MObjc/MCocoa está bajo el MIT ...)

Answer 6

Una bastante larga discusión de los diversos puentes ha tenido lugar en el Mono- Lista de correo de OSX.

La discusión comienza con here Miguel:

• Al anunciar que el cacao # ya no se mantendrá por Novell.
• Intentando unificar los esfuerzos restantes en la comunidad.

Si lee el resto de la discusión, parece que la comunidad Mono se inclina hacia Monoobjc o MObjc/MCocoa; entonces, si estás haciendo tus propias investigaciones, probablemente sean ellos quienes se concentren.