¿Qué recomendarías para el desarrollo de OS X de una aplicación gráfica como las posibles en WPF?Rich GUI OS X Frameworks?
Mi fondo específico está en Smalltalk & Java, pero actualmente trabajo principalmente en DHTML/.NET (ASP.NET/C#).
Cocoa. Considerado por muchos como el mejor marco de aplicación de la historia. El lenguaje es Objective-C, un lenguaje similar a SmallTalk que inspiró a los creadores de Java.
Realmente, no existe una alternativa razonable a Cocoa para el desarrollo de OS X, a menos que tenga necesidades específicas como querer ser multiplataforma.
No estoy seguro de qué es WPF, pero la mayoría del desarrollo para la plataforma OSX se realiza en Objective-C con Cocoa. Puede utilizar las API de Carbon en desuso con otros lenguajes como Java, pero las aplicaciones nuevas para OSX realmente deberían desarrollarse en Objective-C. Puede comenzar con Apple's guide con XCode como su IDE.
Cocoa es el marco principal para usar en Mac OS X. Es lo que Apple usa, es lo que usa la mayoría de los nuevos desarrollos, y es donde las nuevas características se agregan principalmente.
Si vienes de WPF, creo que puedes encontrar algunos de los conceptos en Cocoa familiar. (A pesar de que Cocoa es solo un poco más viejo.) Está construido completamente en torno a MVC, hay notificaciones y enlaces de cambio de propiedad, hay soporte de animación, persistencia y marco de gestión de gráficos de objetos, y más.
(Además, es posible que desee añadir "mac" a las etiquetas.)
Aparte de Interface Builder que se incluye como parte de las herramientas Xcode, también se puede utilizar QT, GTK +, AWT & Swing (para su fondo de Java), Tk, Squeak (para su fondo de Smalltalk), Zapatos (pequeño kit de herramientas de GUI de Ruby muy atractivo), FXRuby (más Ruby), wxWidgets, XULRunner y otros, estoy seguro de que lo he olvidado. Sin embargo, para las aplicaciones más nativas, Interface Builder es tu mejor opción.
Con su fondo Java, no se deje desviar por el puente Cocoa-Java, ahora en desuso. Al principio de la historia de OS X, Apple proporcionó una interfaz de Java (laboriosamente mantenida a mano) para las bibliotecas de Cocoa. Debido a las diferencias semánticas entre Java y Objective-C, muchas de las funciones más potentes de Cocoa, incluida la vinculación de valores clave (sobre la que se crean muchas otras características) es muy difícil, lo que lleva a la divergencia de las capacidades de Objective-C y Java. la eventual desaprobación del puente. Todo el desarrollo de Cocoa se realiza mejor con Objective-C o uno de los muchos (automáticamente generados) puentes a lenguajes dinámicos como Python o Ruby.
Con su experiencia en smalltalk, esperaría que pudiera elegir Objective-C en uno o dos días.
Para decirlo de una manera diferente a los carteles anteriores: si no está diseñando su interfaz en InterfaceBuilder y manipulándola con Objective-C, entonces va a terminar con una aplicación que no se ve, se siente, no actúa, o funciona del mismo modo que una aplicación de Macintosh, y se destacará como un pulgar doloroso para los usuarios. Será una experiencia desagradable para el usuario en comparación con otras aplicaciones, y es probable que desee una aplicación diferente debido a eso.
Los kits de herramientas como QT son aceptables si su aplicación ya usa QT y desea portarla rápidamente, pero si está escribiendo una nueva aplicación (o una GUI separada), escríbala en Cocoa usando ObjC u ObjC++.
Puede echar un vistazo a PyObjc que es un puente entre el lenguaje de programación Python y Objective-C, incluidos los enlaces para los componentes de Mac OS X, incluido Cocoa.
Con un fondo Smalltalk, recomendaría directamente Cocoa y Objective-C. Sin embargo, si se inclina por un lenguaje dinámico, RubyCocoa le permitirá usar Ruby, que creo que le resultará más fácil de recoger que Python.