¿Por qué no se escriben más aplicaciones de escritorio con Qt? [cerrado]

Hasta donde sé y he entendido en mi experiencia con Qt, es una biblioteca muy buena y fácil de aprender. Tiene una API muy bien diseñada y es multiplataforma, y ​​estas son solo dos de las muchas características que lo hacen atractivo. Me interesa saber por qué más programadores no usan Qt. ¿Hay una deficiencia que habla en contra de ella? ¿Qué característica hace que otras bibliotecas sean mejores que Qt? ¿El problema está relacionado con la licencia?

Realmente no pretendo que sea una respuesta contundente, pero estas son las razones por las que no uso personalmente Qt. Hay muchas cosas buenas que decir al respecto, a saber, que la API funciona la mayor parte del tiempo y que conecta plataformas sin problemas. Pero no uso Qt, porque:

1. En algunos casos, simplemente no se parece a los programas nativos. Diseñar una sola interfaz de usuario para todas las plataformas inherentemente no se verá bien cuando se mueva de una máquina a otra, por varias razones de estilo visual. Por ejemplo, en las máquinas Mac, las barras divididas suelen ser relativamente gruesas y los botones son pequeños y redondeados con iconos. En las máquinas con Windows, las barras divididas suelen ser estrechas y los botones son más textuales, con diseños más cuadrados. El hecho de que pueda escribir una IU para cada plataforma no significa que deba hacerlo para la mayoría de las aplicaciones.
2. Qt no es una biblioteca de C ++. Requiere un paso de compilación separado, lo que hace que el proceso de compilación sea mucho más complicado en comparación con la mayoría de las otras bibliotecas.
3. Como resultado de (2), las herramientas y los IDE de C ++ pueden marcar las expresiones Qt como errores, porque no entienden los detalles específicos de Qt. Esto casi fuerza el uso de QtCreator o un editor de solo texto como vim.
4. Qt es una gran cantidad de fuente, que debe estar presente y preinstalada en cualquier máquina que use antes de compilar. Esto puede hacer que configurar un entorno de compilación sea mucho más tedioso.
5. Está disponible solo bajo LGPL, lo que hace que sea difícil usar una implementación binaria única cuando se necesita lanzar bajo una licencia más restrictiva o menos restrictiva.
6. Produce binarios compilados extremadamente grandes en comparación con "aplicaciones nativas simples" escritas de manera similar (excepto las aplicaciones de curso escritas para KDE).

Como dice la gente, cada herramienta se adapta a cada problema y situación ...

Pero si eres programador de C ++, Qt es tu marco. Sin rival

Desarrollamos una aplicación comercial de imágenes médicas complejas, y Qt se mantiene.

No digo que los 'inconvenientes' que la gente dice al respecto sean falsos, pero tengo la sensación de que no han probado Qt durante mucho tiempo (mejora continuamente en cada nueva versión ...) Y, sobre todo todos los problemas que comentan no son un problema si te cuidas.

Incoherencia de la plataforma de la interfaz de usuario: solo si utiliza los widgets de la interfaz de usuario "tal como son", sin personalización ni arte personalizado.

Sobrecarga del preprocesador Qt: solo si abusa del mecanismo de ranura de señal o de la herencia QObject, cuando realmente no es necesario.

Por cierto, todavía escribimos aplicaciones en C # .NET, y lo hemos estado haciendo durante mucho tiempo. Entonces creo que tengo una perspectiva de enouch.

Como dije, cada herramienta para cada situación,

pero Qt es sin duda un marco consistente y útil.

De todas las cosas que no me gustan de Qt, el hecho de que no funcione bien con las plantillas es lo que más me molesta. No puedes hacer esto:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Tampoco funciona bien con el preprocesador. No puedes hacer esto:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Eso, mezclado con el hecho de que todo lo que responde a una señal tiene que ser un Q_OBJECT, hace que Qt sea difícil de trabajar para un programador de C ++. La gente acostumbrada a la programación al estilo Java o Python probablemente sea mucho mejor en realidad.

De hecho, pasé mucho tiempo y esfuerzo investigando e ideando una forma de recuperar la seguridad de tipos y conectar una señal Qt a cualquier objeto de functor: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

El tipo de cosas que quiero hacer allí es el desarrollo básico y cotidiano de C ++ hecho casi imposible por el Qt moc ... que en sí mismo es completamente innecesario hoy en día, si alguna vez lo fue.

Francamente, estoy atascado con eso porque si quieres hacer pruebas automatizadas de UI, Qt es prácticamente el único juego en la ciudad que no sea MFC ... que es tan 1980 (apesta trabajar en esa mierda realmente duro). Algunos podrían decir WX pero tiene problemas aún más serios. GTKmm habría sido mi primera opción, pero dado que todo está dibujado por el propietario y no tiene accesibilidad ... no puede ser manejado por el software de prueba estándar de la industria. Qt es bastante difícil en ese sentido ( apenas funciona cuando modifica el complemento de accesibilidad).

Una razón para no usar Qt es que si solo escribe para una arquitectura, como Windows, es posible que desee usar C # / .NET (o Cocoa en Mac) porque invariablemente podrán aprovechar las últimas campanas y silbidos del sistema operativo.

Si está escribiendo aplicaciones multiplataforma, es posible que ya tenga mucha experiencia en otra tecnología como Java (es decir, trabaje en una "Tienda Java"). Su elección de tecnología puede estar dictada por el ecosistema en el que se está desarrollando, como las API específicas del idioma. En este tipo de casos, minimizar el número de tecnologías puede ser beneficioso.

Una tercera razón por la que puedo pensar es que Qt se basa en C ++, y C ++ es un lenguaje relativamente difícil / peligroso para programar. Creo que es un lenguaje para profesionales. Si necesitas tener un rendimiento superior y ser capaz de ser meticuloso, entonces C ++ probablemente sea el mejor juego de la ciudad. En realidad, Qt mejora muchos de los problemas de administración de memoria si configura las cosas para que se salgan del alcance. Además, Qt hace un buen trabajo al aislar al usuario de muchos de los desagradables problemas de C ++. Cada idioma y marco tiene sus pros y sus contras. Es un tema muy, muy complicado que generalmente se puede resumir en el detalle que se suele ver en los comensales: velocidad, calidad y precio (pero solo puede elegir dos).

Aunque las reglas dicen que debo mantenerme enfocado en responder la pregunta, quiero refutar algunos de los problemas planteados por Billy ONeal, quien creo que hace un buen trabajo al resumir las razones comúnmente citadas para no usar Qt:

1. Qt es de hecho una biblioteca de C ++ / framework / archivos de encabezado. Se aumentapor un procesador macro (moc) que permite señales y ranuras, entre muchas otras cosas. Transforma comandos de macro adicionales (como Q_OBJECT) para que las clases tengan introspección y todo tipo de otras ventajas que podría considerar como agregar funcionalidad Objective-C a C ++. Si sabe lo suficiente sobre C ++ como para ofenderse por esta falta de pureza, es decir, si es un profesional, entonces 1) no use Q_OBJECT y su tipo o 2) agradezca que lo haga y programe alrededor de los casos de esquina muy limitados donde esto causa un problema Para las personas que dicen "¡Usa Boost para señales y ranuras!" entonces respondería que estás intercambiando un "problema" por otro. Boost es enorme, y tiene sus propios problemas comúnmente citados, como documentación deficiente, API horrenda y horrores multiplataforma (piense en compiladores antiguos como gcc 3.

2. Para el soporte del editor, esto también se deduce de 1, estoy de acuerdo. En realidad, Qt Creator es, en mi humilde opinión, el mejor editor gráfico de C ++, punto, incluso si no usa el material Qt. Muchos programadores profesionales usan emacs y vim. Además, creo que Eclipse maneja la sintaxis adicional. Por lo tanto, no hay problemas con las macros Qt (Q_OBJECT) o las adiciones de señales / ranuras. Probablemente no encontrará estas macros en Visual Studio, porque (lo reconozco) son adiciones a C ++. Pero, en general, la gente de C # / .NET no va a usar Qt de todos modos, debido al hecho de que tienen mucha de la funcionalidad cubierta con sus propias técnicas patentadas.

3. En cuanto al tamaño de la fuente Qt, siempre que se compile de la noche a la mañana, ¿a quién le importa? Compilé Qt 4 en mi Macbook de doble núcleo en "menos de la noche a la mañana". Ciertamente espero que esto no sea lo que impulsa su decisión de usar o no usar una tecnología en particular. Si esto es realmente un problema, puede descargar los SDK precompilados para Mac, Linux y Windows desde el sitio web de Qt.

4. La licencia está disponible en tres opciones: 1) Licencia patentada en caso de que desee modificar Qt MISMO y no compartir, u ocultar el hecho de que uno está usando Qt y no está dispuesto a otorgar atribución (¡podría ser muy importante para la marca y la imagen!) 2 ) GPL y 3) LGPL. Sí, hay problemas con la vinculación estática (rodar todo Qt en el binario), pero creo que eso es más porque uno no puede mirar dentro y notar que está usando Qt (¡atribución!). Traté de comprar una licencia de propiedad de Digia, y me dijeron "por lo que estás haciendo, realmente no lo necesitas". Guau. De una empresa que se dedica a la venta de licencias.

5. El tamaño del binario / paquete se debe a que debe distribuir el material Qt a las personas que no lo tienen: ¿Windows ya lo tiene? las cosas de Visual Studio o tienes que instalar el tiempo de ejecución. Mac ya viene con el enorme Cocoa, y puede vincularse dinámicamente. Aunque no hago mucha distribución, nunca he encontrado muchos problemas con la distribución del archivo estático de ~ 50 megabytes (que puedo hacer aún más pequeño con algunas de las utilidades binarias de stripper / compresión como UPX). Simplemente no me importa lo suficiente como para hacer esto, pero si el ancho de banda fuera un problema, agregaría un paso UPX a mi script de compilación.

6. ¿Qué define "aspecto y sensación nativos"? Creo que "la mayoría" estaría de acuerdo en que Mac se acerca más a la apariencia unificada. Pero aquí me siento, mirando Safari, iTunes, Aperture, Final Cut Pro, Pages, etc. y no se parecen en nada a pesar de que están hechos por el proveedor del sistema operativo. Creo que el aspecto "sentir" es más relevante: estilo de widget, capacidad de respuesta, etc. Si le preocupa la capacidad de respuesta, aquí hay una buena razón para usar C ++ en lugar de Java, o algún otro lenguaje altamente dinámico. (El objetivo C también oscila, pero estoy tratando de disipar los mitos sobre Qt)

En resumen, es un tema complicado. Pero me gustaría señalar que creo que hay menos razones para "no usar Qt", como se podría pensar en base a mitos e información desactualizada.

Algunos de ellos son licencias. Consulte https://en.wikipedia.org/wiki/Qt_(software)#Licensing para obtener información sobre el historial de licencias. Hasta el año 2000, las personas que se preocupaban mucho por el código abierto no usaban Qt. Período. (Esta fue, de hecho, la motivación original para el desarrollo de Gnome.) Hasta 2005, las personas que querían poder lanzar software gratuito para Windows no usaban Qt. Incluso después de esa fecha, las personas que querían software libre bajo algo diferente a la GPL, simplemente no tenían la opción de usar Qt. Por lo tanto, cualquier proyecto de software libre que sea anterior a esas fechas, no podría usar Qt. Y, por supuesto, las personas que escriben código de propiedad tuvieron que pagar por el privilegio.

Además, no es que falten otras opciones. Por ejemplo , WxWidgets , GTK + y Tk son juegos de herramientas multiplataforma de código abierto.

Además, durante mucho tiempo, Windows fue tan dominante en el escritorio que una gran cantidad de software fue contenido para ejecutarse solo en Windows. Si instala la cadena de herramientas de Microsoft, es más fácil usar las cosas patentadas de Microsoft que preocuparse por cualquier otra cosa, y muchos programadores hicieron exactamente eso.

Estoy de acuerdo con casi todas las razones discutidas anteriormente, sin embargo, muchas personas aquí han dicho que no usarían Qt debido a la sobrecarga adicional que conlleva. No estoy de acuerdo con eso porque todos los lenguajes más comunes hoy en día (Java, C # y Python) conllevan un poco de sobrecarga.

En segundo lugar, Qt hace que la programación con C ++ sea tan fácil y directa que compensa los recursos adicionales que utiliza. Me he encontrado con bastantes aplicaciones de consola escritas en Qt en lugar de C ++ estándar debido a la facilidad con la que se pueden escribir.

Diría que la productividad de Qt es mayor que la de C / C ++ pero menor que lenguajes como Python.

Esto realmente no es un intento de comenzar una guerra de llamas, solo quería abordar algunos de los puntos.

Probablemente, la verdadera razón por la que Qt no se usa más ampliamente es porque es C ++ y menos personas usan c ++ para aplicaciones de escritorio.

Qt no es una biblioteca de C ++. Requiere un paso de compilación separado, lo que hace que el proceso de compilación sea mucho más complicado en comparación con la mayoría de las otras bibliotecas.

El vs-addin para visual studio hace esto automáticamente al igual que el proceso de creación de línea de comandos de Qt. El compilador de recursos utilizado para construir los cuadros de diálogo para MFC también es un paso separado, pero sigue siendo c ++.

Qt es una gran cantidad de fuente, que debe estar presente y preinstalada en cualquier máquina que use antes de compilar. Esto puede hacer que configurar un entorno de compilación sea mucho más tedioso.

Hay una descarga binaria para cada versión de Visual Studio y la compilación desde la fuente es un solo comando. No veo que el tamaño de la fuente del SDK sea tan importante en estos días. Visual Studio ahora instala todas las bibliotecas de C ++ en lugar de permitirle elegir, como resultado, el tamaño de instalación del compilador es> 1Gb.

Está disponible solo bajo LGPL, lo que hace que sea difícil usar una implementación binaria única cuando se necesita lanzar bajo una licencia más restrictiva o menos restrictiva.

La LGPL solo se aplica a la lib, no afecta su código. Sí, significa que tiene que enviar archivos DLL en lugar de un solo binario (a menos que pague), pero en un mundo donde necesita descargar un tiempo de ejecución de Java o una actualización .Net para una pequeña utilidad, esto no es un gran problema. También es un problema menor en plataformas con un solo ABI para que otras aplicaciones Qt puedan compartir las bibliotecas.

En algunos casos, simplemente no se parece a los programas nativos. Diseñar una sola interfaz de usuario para todas las plataformas inherentemente no se verá bien cuando se mueva de una máquina a otra, por varias razones de estilo visual.

Se supone que usa widgets y temas nativos. Debo admitir que hago principalmente aplicaciones técnicas para que mis usuarios no estén demasiado preocupados por el estilo. Especialmente en Windows, la nueva moda de tener todo el estilo como un widget de teléfono inteligente significa que hay cada vez menos un estándar.

La razón es simple: no tiene buenos enlaces a todos los idiomas principales, y mágicamente no siempre es apropiado para el trabajo en cuestión.

Use la herramienta adecuada para el trabajo. Si estoy escribiendo una aplicación de línea de comandos simple, ¿por qué habría de llenarla con Qt por el simple hecho de hacerlo?

Como respuesta más general (que puedo dar porque soy relevante aquí), algunos programadores simplemente nunca lo probarán y decidieron usarlo. En algunos casos, no hay otra razón en particular que el programador nunca haya encontrado una necesidad y lo haya investigado.

Los marcos como Qt son apropiados cuando le preocupa más que su producto tenga el mismo aspecto en todas las plataformas que si su producto se ve bien en todas las plataformas. Cada vez más a menudo en estos días, ese tipo de aplicaciones se están moviendo hacia tecnologías basadas en la web.

Estoy de acuerdo en que Qt es un buen marco para trabajar. Aún así, hay una serie de problemas que tengo con él:

1. Está escrito en C ++, que es un lenguaje de muy bajo nivel. El solo hecho de que sea C ++ hará que cada programador Qt sea significativamente menos productivo en comparación con los Frameworks escritos en otros lenguajes. Mi principal problema con C ++ como lenguaje de desarrollo GUI es que casi no tiene noción de administración automática de memoria, lo que hace que el proceso de desarrollo sea mucho más propenso a errores. No es introspectivo, lo que hace que la depuración sea mucho más difícil. La mayoría de los otros kits de herramientas principales de GUI tienen alguna noción de administración de memoria automática e introspección.
2. Cada kit de herramientas multiplataforma sufre el problema de que solo puede implementar el mínimo común denominador de todas las plataformas compatibles. Eso, y las diferentes pautas de UI en diferentes plataformas cuestionan mucho la conveniencia de las GUI multiplataforma en general.
3. Qt está muy centrado en codificar toda su interfaz de usuario. Aunque puede usar QtDesigner para construir algunas partes de su interfaz de usuario, es muy escaso en comparación con, por ejemplo, (Cocoa / Obj-C) Interface Builder o las herramientas .Net.
4. Aunque Qt incluye una gran cantidad de funcionalidades de aplicaciones de bajo nivel, no se puede comparar con tener un marco hecho a mano para una determinada plataforma. Las bibliotecas nativas del sistema operativo para Windows y OSX son significativamente más potentes que las implementaciones de Qt. (Piense en marcos de audio, acceso a sistemas de archivos de bajo nivel, etc.)

Dicho esto, me encanta usar PyQt para la creación rápida de prototipos de aplicaciones o aplicaciones internas. El uso de Python para hacer toda la codificación alivia las preocupaciones con C ++ y en realidad hace que Qt sea un lugar muy agradable.

Editar, en respuesta a algunos comentarios:

Cuando escribí acerca de que Qt se escribía en C ++, no me quejaba tanto de Qt en sí, sino más del entorno en el que vive. Es cierto que Qt gestiona muy bien sus propios recursos, pero todos los relacionados con la interfaz gráfica de usuario, pero ... el código no Qt también debe escribirse en C ++. Incluso allí, Qt proporciona muchas herramientas agradables, pero en última instancia, debe lidiar con C ++ a ese nivel. Qt hace soportable C ++, pero sigue siendo C ++.

En cuanto a la introspección, lo que quiero decir es esto: los casos más difíciles de depurar son cuando tienes un puntero a algún objeto que no se comporta como crees que debería. Con C ++, su depurador podría mirar un poco dentro de ese objeto (si tiene información de tipo en ese punto), pero incluso eso no siempre funciona. Tome, por otro lado, el cacao en la misma situación. En Cocoa / Obj-C, podría enviar mensajes ('funciones de llamada') a un objeto directamente dentro del depurador. Puede cambiar el estado de los objetos, puede consultar sus atributos, puede pedirle su tipo y los nombres de sus funciones ... Esto puede hacer que la depuración sea mucho más conveniente. Qt / C ++ no tiene nada parecido a eso.

Realmente me gusta Qt, pero es un poco pesado para muchas aplicaciones. A veces simplemente no necesitas ese nivel de complejidad. A veces solo necesitas algo simple sin todos los gastos generales de Qt. No todas las aplicaciones necesitan ser controladas por eventos y C ++ proporciona un conjunto razonable de plantillas. Boost proporciona otro conjunto muy bueno e incluye muchas de las funcionalidades de bajo nivel (archivo, socket, punteros administrados, etc.) que QT hace.

Otras aplicaciones tienen requisitos de licencia que no funcionan bien con GPL, LGPL o la licencia comercial de Qt. La GPL es inapropiada para el software comercial. La LGPL es inapropiada para el software vinculado estáticamente y la licencia comercial cuesta dinero, algo que muchos no están dispuestos a pagar.

Algunos tienen consideraciones de seguridad o estabilidad que no permiten bibliotecas complejas como Qt.

Necesita ejecutar moc para preprocesar sus fuentes. Eso no es un gran problema, pero puede ser desalentador para el nuevo usuario. Muchos programadores piensan que necesitas usar qmake con Qt, pero eso es un nombre inapropiado. Es posible conectar Qt a otros sistemas de compilación con bastante facilidad.

Algunos objetivos tienen mucha memoria o CPU limitada.

Hay algunas trampas específicas de la plataforma en él. La mayoría de esas trampas no están documentadas. Cree una aplicación lo suficientemente grande y se encontrará con ellos y se preguntará qué está pasando (descargo de responsabilidad, la última vez que usé Qt con ira fue hace más de 18 meses, por lo que puede haber mejorado).

Es solo C ++. Existen otros enlaces de idiomas, pero tienden a ocultar o exponer de manera deficiente una gran parte de la funcionalidad para la que desearía Qt.

Hay muchas razones para no usar Qt, por eso hay alternativas. Si todo lo que tienes es un martillo, cada problema se verá como un clavo.

Lo más importante pero no mencionado. En un gran proyecto, una cosa causa tantos problemas y un código no necesario. Los mecanismos de ranura de señal de Qt son ineficientes. Los widgets Qt no proporcionan las señales necesarias para los widgets simples de eventos. Por ejemplo, no puede establecer señales para onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus, etc. Incluso el widget más complejo como QTreeWidget proporciona una o dos señales inútiles ultra simples.

Sí, puedes usar eventos PERO !!! Ha creado una nueva clase para cada widget con evento personalizado. Esta es una gran eficiencia perdida;

• Ha reescrito cada evento de objeto de widget personalizado, hay pequeños cambios.
• Pierdes todas las cosas de Qt Designer. Tienes que promocionar cada widget con eventos personalizados.
• El proyecto se hizo más grande y difícil de mantener.
• Comenzaste a disgustar qt por esto. Y comenzando a hablar sobre cómo .net proporciona delegados, cómo es mucho mucho mejor que la ranura de señal, cómo los componentes .net (widgets) generalmente proporcionan todos los eventos que puedas imaginar. Y etc.

Uno de mi colegio escribió una nueva clase de cuadro combinado para cada widget de cuadro combinado porque tenía que usar algún evento sin señal. Historia verdadera...

Sin embargo, Qt es el mejor marco de UI de C ++ hasta ahora con bajas y subidas.

En mi opinión, aprender a programar en C ++ es más simple que caer en otros lenguajes que ocultan su complejidad, y el programador no sabe qué sucede realmente en segundo plano. Qt, por otro lado, agrega algunos beneficios sobre C ++, para que sea de mayor nivel que C ++ nativo. Por lo tanto, Qt C ++ es un gran marco para quienes desean desarrollar tareas de bajo nivel, o de alto nivel, de la misma manera. C ++ es (según algunas prácticas) un lenguaje complejo y simple. Complejo para quien no quiere desafiarlo, simple para quien le gusta. ¡No lo dejes por su complejidad!

La razón real no es técnica.

Las personas son diferentes. También lo son sus elecciones. La uniformidad no es una característica humana.