2009-12-24 14 views
15

He estado desarrollando plataformas Windows y * nix desde hace bastante tiempo, y estoy buscando avanzar en el desarrollo de Mac. Estoy lanzando entre usar ObjC/Cocoa y C++/Qt4.5.Qt4.5 vs Cocoa para UI nativa de Mac

La semántica de C++/moc tiene más sentido para mí, y mejorar el conocimiento en Qt parece una opción sensata ya que terminas con un conjunto de habilidades que cubre más plataformas.

¿Puedo perjudicar mis aplicaciones salteando Cocoa?

Las aplicaciones Qt de muestra parecen bastante Mac-nativas para mí, pero son bastante simples, así que posiblemente no cuenten toda la historia. ¿Hay otros pros en la forma de Xcode que Qt no tiene, como el empaquetado, la implementación, etc.?

+0

Mucha gente tiene un ojo muy quisquilloso sobre cómo se ve una aplicación "nativa de Mac", y para nosotros, las aplicaciones de Qt no lo cortan. "Uso controles acuáticos" no se traduce en "Soy un buen ciudadano en tu Mac". –

Respuesta

13

Aquí está una manera fácil de contestar:

Si estaban desarrollando una aplicación de Windows con .NET o MFC, ¿podría perjudicar sus aplicaciones mediante el uso de Qt? Si la respuesta es sí, entonces es probable que la situación sea la misma en Mac.

Unos pocos puntos negativos que puedo pensar en la parte superior de mi cabeza:

  • Licencias
  • aplicaciones Qt, aunque bueno, no son del todo una experiencia de interfaz de usuario nativa y hay cosas que un diseñador de interfaz de usuario nativa puede hacer en Cocoa que aturde la mente. Si bien no puedo estar seguro de que la misma funcionalidad no esté disponible en Qt, lo dudo.
  • Qt siempre está un poco atrás. Si Microsoft o Apple salen con una excelente tecnología nueva, tienes que esperar a que los desarrolladores de Qt actualicen Qt.

Sin embargo, con todo lo dicho, solo usted puede determinar el valor comercial de usar Qt. Si crees que el desarrollo multiplataforma será una parte importante de tu desarrollo, entonces Qt podría valer la pena, a pesar de los problemas mencionados.

+2

Bien explicado, ¡gracias! Creo que la licencia de QT es bastante liberal desde que Nokia se hizo cargo. – Scott

+0

En la actualidad, QT tiene licencia LGPL 2.1, GPL 3.0 o una licencia comercial, por lo que es muy flexible. La LGPL es perfectamente buena para aplicaciones comerciales, siempre que siga unos simples requisitos (la vinculación dinámica simplifica muchas cosas). Consulte http://qt.nokia.com/products/licensing para obtener todos los detalles. – gavinb

+4

Además, puede acceder a la API nativa en Qt y hacer cosas que "desordenan la mente". Entonces esa es una respuesta bastante desinformada. – anno

1

Según el tipo de aplicaciones que desee escribir, otro contendiente es REALbasic.

El paso de C++ es bastante fácil (tengo 15 años de experiencia en C++) y el framework y el IDE son extremadamente productivos. Tienes la ventaja añadida de poder implementar en Linux y Windows con un esfuerzo trivial.

La gran razón para aprender Cacao y codificar en Objective-C es si quieres perfeccionar tus habilidades con el iPhone o si estás persiguiendo una experiencia de usuario realmente sofisticada. Si quisieras competir con la vanguardia del desarrollo de WPF, entonces recomendaría Cocoa.

3

Actualmente estoy desarrollando tanto con QT (en realidad PyQT, pero no hace diferencia a su pregunta) como con la aplicación Cocoa nativa. Para mí no es pan comido, elegí Cocoa. Realmente vale la pena el tiempo para explorar Cocoa en general, hay muchos conceptos geniales en el marco de Cocoa y Objective-C 2.0 también.

+0

Cocoa parece una API fuerte. La semántica de transmisión de mensajes realmente parece tener sentido para las cosas de IU/devolución de llamada. – Scott

+0

Si desea explorar Objective-C con más profundidad, le recomiendo Learn Objective-C en la Mac (http://www.apress.com/book/view/1430218150) y para Cocoa, un libro clásico es Cocoa (R) Programación para Mac (R) OS X (http://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/0321503619). –

1

DO NO utilice Qt para una aplicación Mac. No obtendrá aceleración de hardware para el renderizado 2D, y no podrá cumplir con la ADA.

+0

Sin aceleración de hardware? Esa es una gran preocupación. – Scott

+0

Otra cosa que debe tener en cuenta es que si necesita soporte técnico, Apple admite Cocoa. Apple no es compatible con Qt. – NSResponder

+0

¿No obtiene la aceleración OpenGL ordinaria para sus elementos UI 2D? – e8johan

3

Usaría Qt si desea que esta sea una aplicación de plataforma cruzada.

+1

Las realizaciones de Mac de mis aplicaciones multiplataforma son una mierda. No lo hagas Las mac mac apps son creadas por mac shop. –

2

Hago un montón de desarrollo multiplataforma (Mac, Windows, Linux), y para algunos proyectos uso Qt. Es un marco fino y proporciona una biblioteca de clases enriquecedora.Si necesita implementar en múltiples plataformas, no puede permitirse gastar el tiempo/esfuerzo en front-ends específicos de la plataforma, o el soporte "genérico" para cada plataforma es lo suficientemente bueno, entonces use Qt.

Sin embargo, Qt inevitablemente sufre de alguna manera desde el síndrome de denominador común más bajo, y en ocasiones no se siente bastante lo suficientemente nativo. También hay ciertas características que son difíciles de admitir o simplemente no se proporcionan en las bibliotecas de Qt. Por lo tanto, si puede permitirse el tiempo y el esfuerzo necesarios, o si su aplicación realmente exige atención al detalle y ajuste al acabado &, puede que valga la pena desarrollar interfaces independientes.

En cualquier caso, debe escribir su código de back-end (también conocido como dominio) en una plataforma neutra y neutral de front-end. De esta forma, el front-end se reemplaza fácilmente o se modifica entre plataformas.

Siempre puede comenzar con un front-end de Qt e ir rápidamente al mercado, luego desarrollar un front-end nativo más adelante.

En la práctica, me he dado cuenta de que una aplicación Qt en Windows parece más "nativa", mientras que en Mac hay ciertos signos indicadores sutiles que la hacen ver/sentir no del todo bien. ¡Y los usuarios de Mac tienden a tener expectativas mucho más altas cuando se trata de UI/UX!

+0

"Siempre se puede comenzar con un front-end Qt e ir rápidamente al mercado, luego desarrollar un front-end nativo más adelante". Esta es una idea extremadamente mala. Solo tienes una oportunidad de dar tu primera impresión. – NSResponder

5

Pregúntese: ¿cuántas de las mejores aplicaciones de Mac que conoce utilizan Qt en lugar de Cocoa nativo?

Para nuestros sistemas robóticos, originalmente escribimos nuestro software de control en C++ utilizando la biblioteca wxWidgets multiplataforma (evitamos Qt debido a algunas cuestiones de licencia), porque sentimos que teníamos que apuntar a plataformas Windows, Linux y Mac para nuestros usuarios finales. Esto es lo que enviamos durante más de un año hasta que comencé a jugar con Cocoa.

Inmediatamente, lo que más me impresionó fue lo rápido que podía desarrollarse usando Cocoa. Eventualmente, decidimos dejar de apoyar a Linux y Windows y reescribir todas nuestras aplicaciones de control en Cocoa. Lo que nos llevó años reunir en C++ requirió solo tres meses para volver a implementarse por completo en Cocoa.

Aparte de los problemas de interfaz del "denominador común más bajo" que otros han señalado, el rápido desarrollo permitido por Cocoa se ha convertido en una ventaja competitiva para nuestra empresa. Nuestro software ha avanzado mucho más rápido desde nuestra conversión a Cocoa, y nos ha permitido como una nueva compañía con un desarrollador para llegar incluso a los competidores de 10 años que tienen equipos de desarrollo de 20 hombres. Esta parece ser una historia común en el espacio de desarrollo de Mac, donde se ven muchos equipos pequeños que pueden crear productos que compiten con los de compañías mucho más grandes.

Como nota final, el uso de Cocoa le permite mantenerse al tanto de las nuevas API que Apple está implementando continuamente. Ahora estamos trabajando en una nueva interfaz de control que hará un uso intensivo de Core Animation, algo que sería doloroso para lidiar con el uso de Qt.

+5

Debo señalar, sin embargo, que Qt es * manera * más potente y completo que WxWidgets. Wx está muy limitado a la creación gráfica de UI, mientras que Qt ofrece un entorno de aplicación completo que incluye analizadores, redes, audio, etc. Como tal, Qt es mucho más comparable a Cocoa que a Wx. – bastibe

+1

Una historia genial, pero no creo que tu éxito haya tenido mucho que ver con cambiar a Cocoa API. Como ya señaló Bastibe, wxWidgets tiene una funcionalidad limitada. Es muy probable que Qt hubiera hecho el mismo o mejor trabajo. En cuanto a eliminar el soporte de Linux y Windows, lo llamaría un paso atrás. Mac, desafortunadamente, es un mercado muy pequeño. Estoy bastante seguro de que su éxito vino de hacer una interfaz limpia, receptiva y fácil de usar y agregar algunas características nuevas, todo lo cual puede hacer con Qt y C++. – Ignas2526

3

Puede echar un vistazo a la clase QMacCocoaViewContainer. Actúa como una especie de envoltorio para las vistas de Cacao genéricas, por lo que también puede tener elementos de Cacao que oficialmente no son compatibles con Qt.

Por supuesto, esto significa aprender un poco sobre Cocoa y Objective C y cómo debería ser una interfaz de usuario Cocoa. Pero si ya conoce bien Qt y si no es que su aplicación es todo y solo acerca de la GUI, podría ser una buena forma de hacerlo.

Y no se olvide del QMacStyle::WidgetSizePolicy o no entenderá por qué sus mesas salen tan grandes.

2

Desde que publiqué esto, he estado aprendiendo el método Cocoa/Objective-C, y he quedado bastante impresionado. A pesar de lo que inicialmente pensé que era una sintaxis bastante peculiar, Objc parece ser un lenguaje muy efectivo para implementar el código UI, y el azúcar XCode - cosas como Core Data y enlaces - hacen un breve trabajo de todos los bits aburridos.

Pasé un tiempo con los ejemplos de QT y la documentación antes de excavar en el cacao, y estoy más de acuerdo con lo que se ha dicho anteriormente, aunque ligeramente más atrás de la curva, aunque desde una inspección bastante trivial. Si tuviera que construir una aplicación multiplataforma, probablemente usaría QT en lugar de tratar de separar el código de UI, ya que parece que proporcionaría imágenes lo suficientemente cercanas, pero para Mac solo, Cocoa parece una victoria definitiva.

Gracias por todas sus respuestas, ¡todas han sido de gran ayuda!

3

Obviamente, la mejor opción es utilizar un paquete multiplataforma que admita widgets nativos. Con QT4 puede construir su interfaz de usuario base. Luego solo agrega soporte nativo para tu plataforma de destino específica.

Claro, Cocoa tiene un montón de cosas de lujo (y aún puedes usarlas a través de QT4), pero déjame ser claro. Veo muchas aplicaciones sofisticadas en la AppStore, bonitas, pero la mayoría de ellas son basura, caras ... lo que sea. Realmente extrañé mi editor de texto Kate, mi visor visual okular, mi software de dibujo krita ... esas son mejores que las alternativas comerciales y costosas y son gratis. así que simplemente modifiqué un poco el código fuente y obtuve una experiencia real y excelente REAL.

¿Qué pasa si tengo que usar una aplicación de Linux en mi computadora principal con es un mac os x? o ventanas? ¿o lo que sea? ¿solamente?

Por ejemplo, ¿por qué tengo que comprar un software editor de imágenes caro, lujoso pero mucho menos destacado para mi mac como pixelmator cuando puedo usar un software completo de manipulación de imágenes reales como Gimp? YES Gimp está basado en gtk2, lo cual es un problema en cualquier plataforma, especialmente en Mac porque es realmente feo. Gimp debe ser portado a QT4. Inkscape también debería ser portado a QT4, y se sentiría tan bien.

Es tan simple de hacer ... ¡Dios mío! http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html Incluso se puede añadir soporte para los menús de la nueva función de pantalla completa nativo león, título unificado y la barra de herramientas, etc

Yo, como usuario, lo que realmente importa aplicaciones plataforma eficiente, destacados, buenos y transversales, i don Realmente me importa la comodidad o la pereza del desarrollador.

Cuestiones relacionadas