Cerrado . Esta pregunta está
basada en opiniones . Actualmente no acepta respuestas.
Comentarios
Respuesta
Realmente no pretendo que esto sea una respuesta contundente, pero estas son las razones por las que lo hago no utilizo Qt personalmente. Hay muchas cosas buenas que decir al respecto, a saber, que la API funciona la mayor parte del tiempo y que hace un puente entre plataformas sin problemas. Pero no uso Qt porque:
- En algunos casos, simplemente no se parece a los programas nativos. El diseño de una única interfaz de usuario para todas las plataformas 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 están 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 interfaz de usuario para cada plataforma no significa que debería hacerlo para la mayoría de las aplicaciones.
- Qt no es solo un conjunto de bibliotecas de C ++ enlazables. El sistema de compilación que se utiliza requiere la traducción de ciertos archivos en archivos de origen adicionales, 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.
- Como resultado de (2), IDE de C ++ y herramientas puede marcar expresiones de Qt como errores, porque no comprenden las especificaciones de Qt. Esto casi obliga al uso de QtCreator o un editor de texto solo como
vim.
- Qt es una gran cantidad de código fuente, que debe estar presente y preinstalado en cualquier máquina que utilice antes de compilar. Esto puede hacer que la configuración de un entorno de compilación sea mucho más tediosa.
- Las piezas se licencian principalmente bajo la LGPL, lo que hace es difícil usar una implementación binaria única cuando se necesita publicar bajo una licencia más restrictiva o menos restrictiva.
- Produce binarios compilados extremadamente grandes en comparación con " plain ol «aplicaciones nativas " (excepto, por supuesto, las aplicaciones escritas diez para KDE).
Comentarios
Responder
Como dice la gente, cada herramienta se adapta a cada problema y situación …
Pero si eres un programador de C ++, Qt es tu marco. No hay rival.
Desarrollamos una aplicación comercial de imágenes médicas compleja, y Qt se mantiene.
No digo eso los «contras» que la gente dice al respecto son falsos, pero tengo la sensación de que no han probado Qt durante mucho tiempo (está mejorando continuamente en cada nueva versión …) Y, sobre todo, todos los problemas que comentan no son un problema si tiene cuidado.
Incoherencia de la plataforma de la interfaz de usuario: solo si usa los widgets de la interfaz de usuario «como están», sin personalización o arte personalizado.
Sobrecarga del preprocesador de Qt : Solo si abusa del mecanismo de ranura de señal, o la herencia de QObject, cuando realmente no hay necesidad.
Por cierto, todavía escribimos aplicaciones en C # .NET, y hemos haciéndolo durante mucho tiempo. Así que creo que tengo suficiente perspectiva.
Como dije, cada herramienta para cada situación,
pero Qt es sin duda un marco coherente y útil.
Comentarios
Respuesta
De todas las cosas que no me gustan de Qt, el hecho de que no funciona bien con las plantillas me molesta más. No puede hacer esto:
template < typename T > struct templated_widget : QWidget { Q_OBJECT; public signals: void something_happened(T); };
Tampoco funciona bien con el preprocesador. No puede «hacer esto:
#define CREATE_WIDGET(name,type) \ struct name ## _widget : QWidget \ { \ Q_OBJECT; \ \ public signals: \ void something_happened(type); \ }
Eso, combinado 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 de estilo Java o Python probablemente sea mejor en realidad.
De hecho, dediqué mucho tiempo y esfuerzo a investigar e idear una manera de recuperar la seguridad de los tipos y conectar una señal Qt a cualquier objeto 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 es que alguna vez lo fue.
Sin embargo, francamente, estoy atascado porque si quieres hacer pruebas de IU automatizadas, Qt es prácticamente el único juego en la ciudad aparte de MFC. … que es tan de 1980 (es una mierda trabajar en esa mierda realmente difícil). Algunos podrían decir WX pero tiene problemas aún más serios. GTKmm habría sido mi primera opción, pero como todo está diseñado por el propietario y no tiene accesibilidad … no puede ser impulsado por el software de prueba estándar de la industria. Qt es lo suficientemente difícil en ese sentido ( apenas funciona cuando modificas el complemento de accesibilidad).
Comentarios
Respuesta
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 poder aprovechar las últimas novedades del sistema operativo.
Si está escribiendo aplicaciones multiplataforma, es posible que ya esté muy interesado en otra tecnología como Java (es decir, trabaja en una «Tienda Java»). Su elección de tecnología puede estar determinada por el ecosistema en el que está desarrollando, como las API específicas del lenguaje. En este tipo de casos, minimizar el número de tecnologías puede ser beneficioso.
Una tercera razón en la que puedo pensar es que Qt se basa en C ++, y C ++ es un lenguaje comparativamente difícil / peligroso para programar en Creo que es un lenguaje para profesionales. Si necesitas un rendimiento superior y eres capaz de ser meticuloso, entonces C ++ es probablemente el mejor juego de la ciudad. En realidad, Qt mejora muchos de los problemas de administración de la memoria si configura las cosas para que se salgan de su alcance. Además, Qt en sí mismo hace un buen trabajo aislando 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 agregado que se ve a menudo en los comensales: velocidad, calidad y precio (pero solo puede elegir dos).
Aunque las reglas dicen que debo mantener centrado en responder la pregunta, quiero refutar algunas de las cuestiones planteadas por Billy ONeal, quien creo que hace un buen trabajo al resumir las razones comúnmente citadas para no usar Qt:
-
Qt es de hecho una biblioteca / marco / archivos de encabezado de C ++. Está aumentado por un macroprocesador (moc) que habilita 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 pensar que agregan la funcionalidad Objective-C a C ++. Si sabe lo suficiente sobre C ++ como para sentirse ofendido por esta falta de pureza, es decir,usted es un profesional, entonces 1) no use Q_OBJECT y su tipo o 2) agradezca que lo haga y programe en los casos muy limitados en los que esto cause un problema. Para las personas que dicen «Use Boost para señales y tragamonedas! «, entonces respondería que está 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.3 y grandes compiladores de hierro como AIX).
-
Para el soporte del editor, esto también se deduce de 1, estoy un poco de acuerdo. En realidad, Qt Creator es IMHO el mejor editor gráfico de C ++, punto , incluso si no usa las cosas Qt. Muchos programadores profesionales utilizan 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 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 muchas de las funciones cubiertas con sus propias técnicas propietarias.
-
En cuanto al tamaño de la fuente Qt, siempre y cuando 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 impulse su decisión de usar o no 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.
-
La licencia es disponible en tres opciones: 1) Licencia propietaria en caso de que desee modificar Qt SÍ 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 e imagen!) 2) GPL y 3) LGPL. Sí, hay problemas con la vinculación estática (enrollar todo Qt en el binario), pero creo que eso es más porque uno no puede mirar adentro y notar que está tu canta Qt (atribución!). Intenté comprar una licencia propietaria de Digia y me dijeron «para lo que estás haciendo, realmente no lo necesitas». Vaya. De una empresa que se dedica a la venta de licencias.
-
El tamaño del binario / paquete se debe a que tienes que distribuir el material de Qt a la gente que no lo tiene: ¿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 se puede vincular 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 eliminación / compresión como UPX). Simplemente no lo hago 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.
-
¿Qué define «Native Look and Feel?» Creo que «la mayoría» estaría de acuerdo en que Mac se acerca más a la apariencia unificada. Pero aquí estoy sentado, 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 de «sensación» es más relevante: estilo de widget, capacidad de respuesta, etc. Si le importa 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. (Objective C también es genial, 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.
Comentarios
Respuesta
Parte de esto es licencia. Consulta https://en.wikipedia.org/wiki/Qt_(software) #Licensing para ver parte del 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 más antiguo que esas fechas, no podría usar Qt. Y, por supuesto, la gente que escribe código propietario tuvo que pagar por el privilegio.
Además, no es como si hubiera un escasez de otras opciones. Por ejemplo, WxWidgets , GTK + y Tk son todos conjuntos 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 se contentaba con ejecutar únicamente 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 precisamente eso.
Comentarios
Respuesta
Estoy de acuerdo con casi todas las razones mencionadas 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 el 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 la de lenguajes como Python.
Comentarios
Respuesta
Esto realmente no es un intento de iniciar 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 que es C ++ y menos personas usan C ++ para aplicaciones de escritorio.
Qt no es una biblioteca C ++. Requiere un paso de compilación por 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 propio proceso de creación de línea de comandos de Qt. El compilador de recursos usado para construir los diálogos para MFC también es un paso separado, pero sigue siendo C ++.
Qt es una gran cantidad de código fuente, que debe estar presente y preinstalado en cualquier máquina que utilice antes de compilar. Esto puede hacer que la configuración de un entorno de compilación sea mucho más tediosa.
Hay una descarga binaria para cada versión de Visual Studio y la compilación desde la fuente son 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 librerías de C ++ en lugar de permitirle elegir y elegir, como resultado, el tamaño de instalación del compilador es> 1Gb.
It » s disponible solo bajo LGPL, lo que dificulta el uso de implementación binaria única cuando se necesita publicar bajo una licencia más restrictiva o menos restrictiva.
La LGPL solo se aplica a la biblioteca, no afecta su código. Sí, significa que debe enviar archivos DLL en lugar de un solo binario (a menos que pague), pero en un mundo en el que necesita descargar un tiempo de ejecución de Java o una actualización de .Net para una pequeña utilidad, esto no es tan importante. «también es un problema menor en plataformas con una sola ABI para que otras aplicaciones de Qt puedan compartir las bibliotecas.
En algunos casos, simplemente no» Parece que los programas nativos se ven.Diseñar una interfaz de usuario única para todas las plataformas no se verá bien cuando se mueva de una máquina a otra, por varias razones de estilo visual.
Se supone para usar 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 en sí mismo como un widget de teléfono inteligente significa que cada vez hay menos estándar.
Comentarios
Respuesta
La razón es simple: no tiene buenos enlaces a todos los lenguajes principales, y no es mágicamente siempre apropiado para el trabajo en cuestión.
Utilice la herramienta adecuada para el trabajo. Si estoy escribiendo una aplicación de línea de comandos simple, ¿por qué debería aumentarla con Qt solo por el simple hecho de hacerlo?
Como una respuesta más general (que puedo dar porque soy relevante aquí ), algunos programadores simplemente nunca lo habrán intentado y decidido a usarlo. En algunos casos, no hay ninguna razón en particular aparte de que el programador nunca ha encontrado una necesidad y la ha investigado.
Comentarios
Respuesta
Los marcos como Qt son apropiados cuando estás más preocupado por la apariencia de tu producto igual en todas las plataformas que con su producto con un aspecto correcto en todas las plataformas. Hoy en día, este tipo de aplicaciones se está moviendo cada vez más a menudo hacia tecnologías basadas en la web.
Responder
En mi propia 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é realmente sucede en segundo plano. Qt, por otro lado, agrega algunos beneficios sobre C ++, para hacerlo más alto que el C ++ nativo. Por lo tanto, Qt C ++ es un gran marco para quien quiera 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!
Respuesta
Estoy de acuerdo en que Qt es un buen marco para trabajar. Aún así, hay una serie de problemas que tengo con él:
- Está escrito en C ++, que es un lenguaje de muy bajo nivel. 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. Mi principal problema con C ++ como lenguaje de desarrollo de GUI es que no tiene casi ninguna 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 dificulta mucho la depuración. La mayoría de los otros conjuntos de herramientas de GUI importantes tienen alguna noción de administración automática de memoria e introspección.
- Cada conjunto de herramientas multiplataforma adolece del problema de que solo puede implementar el mínimo común denominador de todas las plataformas compatibles. Eso, y las diferentes pautas de IU en diferentes plataformas cuestionan mucho la conveniencia de las GUI multiplataforma en su conjunto.
- Qt se centra en gran medida en codificar toda su IU. Aunque puede usar QtDesigner para construir algunas partes de su interfaz de usuario, es muy deficiente en comparación con, digamos, (Cocoa / Obj-C) Interface Builder o las herramientas .Net.
- Aunque Qt incluye muchas funciones de aplicaciones de bajo nivel, no se puede comparar con tener un marco diseñado a mano para una plataforma determinada. Las bibliotecas nativas del sistema operativo para Windows y OSX son significativamente más poderosas que las implementaciones de Qt. (Piense en marcos de audio, acceso al sistema 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. Usar Python para hacer toda la codificación alivia las preocupaciones con C ++ y hace que Qt sea un lugar muy agradable.
Editar, en respuesta a algunos comentarios:
Cuando escribí que Qt estaba escrito en C ++, no me quejaba tanto de Qt en sí , pero más sobre el entorno en el que vive. Es cierto que Qt administra muy bien sus propios recursos, pero todo el código relacionado con la GUI, pero no con Qt, también debe estar escrito en C ++. Incluso allí, Qt proporciona muchos buenas herramientas, pero en última instancia, tienes que lidiar con C ++ en ese nivel. Qt hace que C ++ sea soportable, 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 usted tener un puntero a algún objeto que no se comporte como usted cree que debería. Con C ++, su depurador podría mirar dentro de ese objeto un poco (si tiene información de tipo en ese punto), pero incluso eso no siempre funciona. Tomemos, por otro lado, Cocoa 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.
Comentarios
Respuesta
La más importante pero cosa no mencionada. En un proyecto grande, una cosa causa tantos problemas y código innecesario. Los mecanismos de ranura de señal de Qt son ineficientes. Los widgets de 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 y etc. Incluso el widget más complejo, como QTreeWidget proporciona una o dos señales inútiles ultra simples.
Sí, puede usar eventos PERO !!!, ha creado una nueva clase para cada widget con evento personalizado. Esto es una gran pérdida de eficiencia;
- Ha reescrito cada evento de objeto de widget personalizado; hay pequeños cambios.
- Pierde todo el material de Qt Designer. Tiene que promover cada widget con eventos personalizados.
- El proyecto se hizo más grande y difícil de mantener.
- Comenzó a no gustarle qt debido a esto. Y comenzó a hablar sobre cómo .net proporciona delegados, cómo es mucho, mucho mejor que la ranura de señal, cómo .net componentes (widgets) generalmente proporciona todos los eventos que puedas imaginar. Y etc.
Uno de mis ha escrito una nueva clase de cuadro combinado para cada widget de cuadro combinado porque tuvo que usar algún evento sin señal. Historia real …
Sin embargo, Qt es el mejor framework de UI de C ++ hasta ahora con altibajos.
Comentarios
Responder
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 estar controladas por eventos y C ++ proporciona un conjunto razonable de plantillas. Boost proporciona otro conjunto muy bueno e incluye muchas de las funciones de bajo nivel (archivo, socket, punteros administrados, etc.) que hace QT.
Otras aplicaciones tienen requisitos de licencia que no funcionan bien con GPL , Licencia comercial LGPL o Qt. La GPL no es apropiada para software comercial. La LGPL es inapropiada para 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 abrumador para el nuevo usuario. Muchos programadores piensan que necesitas usar qmake con Qt, pero ese es un nombre inapropiado. Es posible conectar Qt a otros sistemas de compilación con bastante facilidad.
Algunos objetivos son muy memoria o CPU restringida.
Hay algunos errores específicos de la plataforma. La mayoría de esos errores no están documentados. Cree una aplicación lo suficientemente grande y se encontrará con ellos y se preguntará qué está pasando (descargo de responsabilidad, el 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 lenguaje, pero tienden a ocultar o exponer de manera deficiente muchos de los funcionalidad para la que querría Qt.
Hay muchas razones para no usar Qt, por eso hay alternativas. Si todo lo que tiene es un martillo, entonces cada problema se verá como un clavo.
Comentarios
Respuesta
La razón real no es técnica.
La gente sucede ser diferente. También lo son sus elecciones. La uniformidad no es una característica humana.
Comentarios