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

202

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?

Deshumanizador
fuente
6060
Es nativo de C ++. La mayoría de los desarrolladores preferirían lenguajes de nivel superior como C #.
user16764
15
La espada de doble filo de la compatibilidad con versiones anteriores ha dejado a Qt con muchos anacronismos, defectos irreparables y otros comportamientos deficientes.
edA-qa mort-ora-y
26
@ user16764: "¿La mayoría"?
Carreras ligeras en órbita el
17
No creo que el índice TIOBE sea una medida realmente precisa, porque mide la popularidad, no el uso. La comparación de la cantidad de código en repositorios de código abierto como GitHub, Bitbucket, Codeplex y Sourceforge daría mediciones más precisas. (Y creo que esas mediciones más precisas ponen C y C ++ en el # 1 y # 2 puntos - Java tiene una ventaja injusta en el índice TIOBE porque se usa para los cursos universitarios de primer año, y los nuevos programadores a hacer más ruido que los experimentados hacen)
Billy ONeal 01 de
12
@Giorgio: Erm, tienes que pensar en esas cosas en C #. El concepto de "quién posee esto" va mucho más allá de "quién llama delete". El hecho de que los punteros inteligentes lo hagan explícito no es una falla del lenguaje; y si no piensas en esas cosas, también generarás basura en cualquier lenguaje de alto nivel que yo haya visto.
Billy ONeal

Respuestas:

177

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).
Billy ONeal
fuente
11
@Dehumanizer: está la licencia LGPL y está la licencia comercial. La licencia comercial es de miles de dólares por parte del licenciatario, y no permite la redistribución, etc. Para proyectos de código abierto bajo licencias liberales como BSD, MIT o Boost, donde los autores no están ganando toneladas de dinero y desean para liberar su código bajo una licencia liberal, una dependencia de LGPL no es razonable, pero los desarrolladores en cuestión generalmente no pueden permitirse el lujo de una licencia comercial.
Billy ONeal 01 de
27
# 6 es la mayor razón por la que lo evito. Quiero decir, no quiero un programa grande y torpe, y no me gusta estar sujeto a una licencia específica, pero en realidad es la falta de una buena apariencia nativa lo que es un factor decisivo para mí. Las versiones recientes de OSX y Windows específicamente han hecho un trabajo fantástico al hacer que sus interfaces nativas sean bonitas, rápidas y funcionales, y prefiero aprovechar todo el trabajo que ya han hecho por mí; Me parece que muchos programas sin una apariencia nativa me parecen baratos y extravagantes (no siempre, pero me asusta un poco).
Greg Jackson
16
Su número 6 debería haber sido el número 1. Este es, con mucho, el mayor problema con Qt. En muchos casos, simplemente no usa las API nativas. Me gusta que mi software se vea nativo. A los usuarios también les gusta eso. Nunca he visto una aplicación Mac creada con Qt que se pareciera a una aplicación Mac. Tampoco tienen otros usuarios de Mac, y son exigentes con ese tipo de cosas. Pierdes todo el beneficio de ser "multiplataforma" si solo lo usas para crear aplicaciones Linux, que es el único lugar donde parece nativo porque realmente no hay nada nativo.
Cody Gray
41
excepto que el problema de la apariencia 'nativa' ya no existe. La antigua consistencia de las aplicaciones de Windows es ahora una bastardicación de cualquier blobs, resplandores y animaciones únicos que WPF y Silverlight te permitan tener. Eche un vistazo al panel de control de Office o Windows 7 solo para ver cómo incluso el producto estrella de MS tiene una GUI inconsistente en la actualidad. Usuarios de Mac: bueno, tienes un punto muy válido allí.
gbjbaanb 01 de
55
@TrevorBoydSmith: Lo siento, pero te equivocas. Qt es el único marco que utiliza preprocesamiento. Período. Verifique GNOME, FLTK, WX y amigos, y muéstreme un paso de preprocesamiento. No encontrarás uno. Algunas otras bibliotecas vienen con diferentes sistemas de compilación, pero al final del día, son bibliotecas de C ++ que cualquier compilador de C ++ puede construir. En cuanto a "Raw win32 no presente en mis razones", está presente en mis razones como # 5 y # 6.
Billy ONeal
115

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.

Iñigo
fuente
99
+1 Thaks! Solo quería escribir lo mismo. Lo más absurdo es el "argumento no de código abierto / comercial". Asombroso, cuán equivocado muchas personas entienden el término Código Abierto. Qt era de código abierto desde que lo uso (1.4). Y solía tener la licencia más justa: ganar dinero con Qt -> pagar.
Valentin Heinitz
16
Ah, y realmente no se preocupan por la adición de 10 MB DLL de la aplicación contiene 50 MB de arte y más de 200 MB de tutoriales en vídeo y datos :)
Петър Петров
99
El espacio necesario para Qt es barato en estos días.
trusktr
55
Esto coincide bastante con mi experiencia con Qt (el marco de widgets, no he usado QML / QtQuick para nada serio hasta ahora). Es adecuado para escribir aplicaciones grandes con requisitos complejos de IU. Una vez que lo aprendes, puedes ser muy productivo. Los inconvenientes mencionados (paso de compilación separado para el movimiento, archivos ui, etc.) no son un problema si el sistema de compilación está configurado correctamente. Puedo recomendar qmake o cmake.
Nils
desde Qt 5.8 después hay un proyecto llamado Qt Lite que minimiza extremadamente Qt para sus necesidades específicas. esta es una característica comercial;)
SMMousavi
36

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).

Edward extraño
fuente
1
Por interés, ¿cuáles considera que son los principales problemas con WX?
Tom Anderson
77
@Tom: documentación deficiente, especialmente para las cosas nuevas. Los componentes AUI apenas están documentados, ya que faltan secciones grandes, lo que dificulta su uso en un entorno de producción. La documentación para el proceso del evento es fundamentalmente errónea con respecto a la ruta que se sigue, al menos en win32. Pasé mucho tiempo gritando a la computadora, "¡Esto debería estar funcionando!" antes de profundizar en el código de procesamiento profundo para descubrir que lo que hace WX no es seguir los documentos y lo que estaba haciendo NUNCA funcionaría.
Edward Strange
1
También me molestó la aceptación de la biblioteca de cuadrícula de propiedades en la línea principal. Utilicé esa biblioteca y mostró numerosas fallas de diseño fundamentales además de la falta de conocimiento real en nombre del programador que la escribió (llamadas funciones virtuales en los constructores, por ejemplo). Él, y el pobre estado de AUI, mostraron una tendencia a estándares más pobres. Tampoco soy un gran fanático de las tablas de eventos estáticos, aunque al menos hay otra forma de responder a los eventos ... a diferencia de MFC, que WX es demasiado emocionante de todos modos.
Edward Strange
Gracias. Solo lo he usado un poco, y a través de la API wxPython, donde parecía bastante agradable. Puedo apreciar que eso escondería algo del mal, pero también que simplemente no me he involucrado lo suficiente como para enfrentar los problemas más serios. Algo para que tenga en cuenta.
Tom Anderson
1
todo lo que responde a una señal tiene que ser un Q_OBJECT, no en la actualidad ... Ahora, las funciones estáticas, las funciones e incluso las funciones lambda pueden responder a una señal (puede usar punteros de función como ranuras). Las clases No-QObject también pueden tener ranuras para miembros si se conecta a ellas utilizando un std :: bind para convertir el miembro de la instancia en un puntero de función.
Vinícius A. Jorge
28

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.

Eric Brown
fuente
1
Lo que no entiendo es por qué estas bibliotecas multiplataforma no son simplemente funciones de envoltura, o incluso mejor; if defs alrededor de las funciones Cocoa, Win32, KDE / Gnome, asegurando la mejor interfaz de usuario, con todas sus características.
MarcusJ
2
@MarcusJ Escribir un contenedor alrededor de un juego de herramientas no es trivial, no importa 4 o más, pero si crees que es tan fácil, puedes intentarlo. En cuanto a la idea de que esto podría lograrse utilizando solo un preprocesamiento condicional ... debe estar bromeando, ¿verdad?
underscore_d
@MarcusJ libui es exactamente eso (aunque sin soporte de KDE).
Demi
Quiero agregar que ahora puede usar Qt / QML con .NET. No necesitas tocar C ++. github.com/qmlnet/qmlnet PD: Soy el autor.
Paul Knopf
26

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.

btilly
fuente
1
@btilly: GTK + es multiplataforma. Por ejemplo, el cliente Pidgin IM está escrito en GTK +.
Billy ONeal 01 de
1
Ok, sin embargo, es posible 'de alguna manera' correr en Windows :)
Deshumanizer
66
Simplemente instale GIMP en Windows y eche un vistazo.
user281377
2
Sí, y GIMP funciona bien en Windows, pero ciertamente no encaja con el aspecto y la interfaz de usuario de Windows 7.
Alan B
55
Pidgin es probablemente un mejor ejemplo de GTK en Windows. No hace nada elegante, pero ¿encaja y tiene tal vez 10 años o más?
Brendan Long
14

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.

WKS
fuente
2
Supongo que todo es relativo a la experiencia del individuo, porque puedo codificar OK en C ++ 14, pero cada vez que miro algún código Qt, tengo que entrecerrar los ojos para reconocerlo como el mismo idioma ... así que ciertamente no No creo que sea el impulso de productividad unánime lo que estás insinuando aquí.
underscore_d
1
@underscore_d obviamente si conoces muy bien C ++ y no sabes Qt, no serás más productivo con este último. Pero cuando conoce C ++ y Qt, el marco realmente está haciendo que muchas cosas sean más fáciles y rápidas de implementar (C ++ 11, 14, etc., están llenando el vacío, pero aún no del todo).
ymoreau
11

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.

Martin Beckett
fuente
1
Muchas grandes compañías de software crean aplicaciones comerciales en C ++, pero no conozco muchas que usan QT. Entonces, aunque entiendo que los desarrolladores que no son C ++ pueden evitar QT, parece que hay otras razones para evitar QT incluso cuando está escribiendo una aplicación C ++. De hecho, realmente no hay ningún lenguaje multiplataforma y kit de herramientas GUI con el que no pueda encontrar fallas. Parece que el desarrollo multiplataforma es SENCILLAMENTE DURO, y que hacerlo bien nunca es fácil ni gratuito, y que la promesa que hace QT (escriba su GUI una vez y reutilice esa GUI en todas partes) no es suficiente.
Warren P
La mayoría del software de escritorio C ++ está en MFC porque comenzó hace 20 años o utiliza un kit de herramientas interno iniciado hace 20 años para evitar MFC (por ejemplo, MS-Office o Autocad). Dudo mucho que se esté escribiendo en C ++ / CLR con WPF. Pero incluso sin consideraciones multiplataforma, encuentro que Qt es el mejor (¡o al menos peor!) Kit de herramientas de escritorio. Como la mayoría de las personas, nos estamos moviendo hacia un front-end web (posiblemente en QtQuick / QML) y un servidor de servidor C ++, que probablemente usará señales / ranuras Qt pero no gui
Martin Beckett
Estoy de acuerdo. Lo peor peor E incluso en aplicaciones solo para Windows, prefiero depurar problemas de QT que problemas de MFC.
Warren P
@WarrenP: sí, no echo de menos buscar el proyecto de código para todas las cosas que faltan en MFC. Pero con el nuevo amor de MSFT por el código nativo, no han hecho mucho para facilitar la escritura de una interfaz gráfica de usuario.
Martin Beckett el
7

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.

Carreras de ligereza en órbita
fuente
1
Pero Qt proporciona la capacidad de escribir solo aplicaciones de consola. ¿No es así?
Deshumanizador
99
@ Deshumanizador: no tengo idea. Pero, ¿por qué lo usaría para una pequeña herramienta de utilidad? ¿Qué beneficio me traería eso cuando puedo escribir trivialmente la aplicación en C ++ estándar? Parece que estás buscando una razón para usar una biblioteca , que es una forma de programar al revés.
Carreras ligeras en órbita el
12
@Dehumanizer: Como dije, ese es un enfoque hacia atrás. Cuando encuentre la necesidad de una biblioteca, lo sabrá, y luego podrá ir a probar algunas y ver qué se adapta mejor a sus necesidades. Intentar recabar opiniones sobre una biblioteca cuando no tiene un caso de uso es una tontería.
Carreras ligeras en órbita el
3
"Si estoy escribiendo una aplicación simple de línea de comandos, ¿por qué habría de llenarla con Qt por el simple hecho de que existe?" Hay al menos una herramienta no gui muy famosa escrita en Qt - Doxygen :-)
Valentin Heinitz
44
@Dehumanizer, por ejemplo, cuando tiene que lidiar con archivos, xml, unicode, json, regexp, concurency, bases de datos, etc., muy rápido y no desea descargar, adoptar, mantener docenas de bibliotecas de terceros.
Valentin Heinitz
5

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.

Caleb
fuente
4

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.

Bastibe
fuente
11
1. Qt se preocupa por la administración de la memoria por sí solo, no debe llamar a 'eliminar' después de cada 'nuevo'. 1a. C ++ NO es lenguaje de bajo nivel, es lenguaje de alto nivel con 'habilidades' de bajo nivel. 3. Estoy de acuerdo, pero Qt proporciona hacer una interfaz de usuario con QtDesigner y con 'código simple' al mismo tiempo. 4. Acepte nuevamente, pero Qt también proporciona el uso de API nativas.
Deshumanizador
11
a su punto nr 1. Creo que c ++ tiene un tipo de gestión de memoria semiautomática: si usa punteros inteligentes como std :: auto_ptr o boost :: shared_ptr, etc. generalmente no tiene que preocuparse por liberar memoria. Este tipo de contenedores también se pueden crear para otros recursos (archivos, recursos del sistema que deben liberarse). El uso del patrón RAII ayuda mucho con la gestión de la memoria y, a medida que crece, no tiene que preocuparse realmente por la memoria.
deo
8
"El solo hecho de que sea C ++ hará que cada programador de Qt sea significativamente menos productivo en comparación con los Frameworks escritos en otros lenguajes". [cita requerida]
Nathan Osman
44
@ SK-logic: si bien creo que entiendo todas las palabras en su tercera oración, no tengo idea de lo que está diciendo. ¿Qué es un "límite de nivel de abstracción"? Para el caso, su primera oración es falsa, dada la definición de Wikipedia de "lenguaje de bajo nivel".
David Thornley
66
@ SK-logic: la metaprogramación de la plantilla es completa en Turing, y hay personas lo suficientemente inteligentes y conocedoras como para aprovechar eso. RAII no es una gran recolección de basura, pero el hecho de que funcione para todo tipo de recursos lo compensa más o menos. Ahora, específicamente, ¿qué tipo de abstracción funciona en Java pero no en C ++?
David Thornley
3

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.

Adam Hawes
fuente
3

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.

Obrix
fuente
Con respecto a los eventos y la creación de nuevas clases: puede usar filtros de eventos en las clases que necesitan reaccionar a ellos.
MrFox el
"Sí, puedes usar eventos PERO !!! has creado una nueva clase para cada widget con evento personalizado. Esto es una gran pérdida de eficiencia". - NO EXACTAMENTE. Acabo de terminar con bool eventFilter que maneja varios widgets y luego instaloEventFilter (this) en todos los widgets secundarios. ¡Y esto no está perdiendo eficiencia y rendimiento de programación! En realidad, nunca uso "widgets promocionados" ... Dejo caer un widget vacío, lo instalo como eventFilter y reimplemo la mayoría de mis eventos dentro de mi clase principal de cpp. Pruébalo, no te duele :) Puedes personalizar casi TODO en Qt sin crear nuevas clases cada vez
Петър Петров
3

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!

usuario100691
fuente
2

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.

Mouviciel
fuente
¿Es por eso que todas las personas caminan sobre sus piernas? Bueno, aquellos que tienen piernas al menos ...
dtech