tutorial programming gui descargar creator c++ qt user-interface rad qt-designer

c++ - programming - qt gui



GUI codificada a mano contra GUI de Qt Designer (12)

Estoy pasando estas vacaciones aprendiendo a escribir aplicaciones Qt. Estuve leyendo acerca de Qt Designer hace unas pocas horas, lo que me hizo preguntarme: ¿qué usan las personas que escriben aplicaciones del mundo real en Qt para diseñar sus GUI? De hecho, ¿cómo las personas diseñan GUI en general?

Yo, por mi parte, descubrí que escribir el código a mano era conceptualmente más simple que usar Qt Designer, aunque para GUI complejas el diseñador podría tener sentido. Es posible utilizar GUI grandes con Designer, pero con el tiempo pueden ser muy difíciles de administrar a medida que aumenta la complejidad (esta es solo mi opinión). También descargué el código fuente de AmaroK para echar un vistazo a lo que estaban haciendo esos tipos, y encontré muchas llamadas a addWidget () y amigos, pero ninguno de esos archivos XML creados por Designer (aparte: AmaroK tiene que ser mi aplicación favorita siempre en cualquier plataforma).

¿Cuál es, entonces, la forma "correcta" de crear una GUI? Diseñador o código? Permítanos, para esta discusión, considerar los siguientes tipos de GUI:

  1. Diálogos simples que solo necesitan ingresar, mostrar algunos resultados y salir. Supongamos una aplicación que toma una URL de YouTube y descarga el video en el disco duro del usuario. El tipo de aplicaciones con las que es probable que empiece un novato.
  2. GUI de nivel intermedio como, por ejemplo, un editor de notas adhesivas con algunas barras de herramientas / elementos de menú. Tomemos xPad por ejemplo ( http://getxpad.com/ ). Yo diría que la mayoría de las aplicaciones caen en la categoría de "utilidades".
  3. Interfaces de usuario muy complejas, como AmaroK u OpenOffice. Los conoces cuando los ves porque te hacen sangrar los ojos.

Añadiría que una de las razones para usar el diseñador gráfico era la falta de administradores de diseño en Win32, por ejemplo. Solo el posicionamiento absoluto era posible, y hacerlo a mano hubiera sido una mierda.

Desde que cambié de Delphi a Java para aplicaciones de GUI (en 2002), nunca más he usado diseñadores. Me gustan los administradores de diseño mucho más. Y sí, obtienes un código repetitivo, pero mover objetos en un diseñador de UI puede tomar tanto tiempo como cambiar el texto estándar. Además, estaría atrapado con un IDE lento; eso es para el caso de Java / C #, OK, mientras que para Qt (especialmente Qt4) no se aplica. Para Qt3, me pregunto por qué uno debería editar el código generado, ¿no era posible agregar código en otros archivos? ¿Por qué razón?

Acerca de los casos discutidos: 1) Es probable que la GUI codificada a mano sea más rápida de escribir, al menos si conoce sus bibliotecas. Si eres un novato y no los conoces, puedes ahorrar tiempo y aprender menos con un diseñador, ya que no necesitas aprender las API que usas. Pero "aprender menos" es el factor clave, por lo que en ambos casos diría que es una GUI codificada a mano.

2) Las barras de menú son bastante molestas para escribir código. Además, piense en detalles como aceleradores, etc. Aún así, depende de a qué estás acostumbrado. Después de un tiempo, puede ser más rápido escribir ese texto estándar que apuntar y hacer clic en el diseñador para corregir todas esas propiedades, pero solo si realmente puede escribir como en una máquina de escribir (como aquellos administradores para los que escribir comandos Unix es más rápido que usando cualquier GUI).

3) Extendería la respuesta para el caso # 2 a este. Tenga en cuenta que, para las plataformas Win32, es posible que el uso de diseñadores que generan recursos de Win32 sea más rápido de cargar (ni idea de eso).

Sin embargo, me gustaría mencionar un posible problema con el uso de Qt Designer allí. Caso del mundo real: llevó unos segundos (digamos 10) cargar un diálogo complejo de Java (el cuadro de diálogo de Preferencias para el editor de texto de un programador) con muchas opciones. La solución correcta habría sido cargar cada una de las pestañas solo cuando el programador quería verlas (me di cuenta después), agregando un método diferente para cada conjunto de preferencias para construir su GUI.

Si diseñas todas las pestañas y el separador de pestañas junto con un diseñador, ¿puedes hacerlo tan fácilmente? Supongo que podría haber un ejemplo similar en el que una GUI codificada a mano te brinde más flexibilidad, y en una aplicación tan grande, es probable que la necesites, aunque solo sea para fines de optimización.


Construye diferentes partes de tu UI
en diferentes archivos .ui utilizando QtDesigner,
luego agrúpalos (y agrega complicaciones) en el código.

Hay cosas que no puedes hacer en Qt Designer, solo puedes hacerlo en código,
entonces Qt Designer es solo una (gran) parte de la cadena de herramientas .


En mi experiencia con Qt Designer y otros toolkits / UI-tools:

  • Las herramientas de IU aceleran el trabajo.
  • Las herramientas de interfaz de usuario facilitan modificar el diseño más adelante.
  • Las herramientas de interfaz de usuario hacen que sea más fácil / posible para los no programadores trabajar en el diseño de la interfaz de usuario.

La complejidad a menudo puede tratarse en una herramienta de interfaz de usuario dividiendo el diseño en múltiples archivos de interfaz de usuario. Incluya pequeños grupos lógicos de componentes en cada archivo y trate a cada grupo como un widget único que se usa para construir la interfaz de usuario completa. El concepto de Qt Designer de widgets promocionados puede ayudar con esto.

No he encontrado que la escala del proyecto haga la diferencia. Tu experiencia puede variar

Los archivos creados con herramientas de interfaz de usuario (supongo que podría escribirlos a mano si realmente lo desea) a menudo se pueden cargar dinámicamente en tiempo de ejecución (Qt y GTK + proporcionan esta característica). Esto significa que puede hacer cambios de diseño y probarlos sin volver a compilar.

En última instancia, creo que tanto el código sin formato como las herramientas de IU pueden ser efectivos. Probablemente dependa mucho del entorno, del toolkit / UI-tool y, por supuesto, de las preferencias personales. Me gustan las herramientas de UI porque me ayudan a acelerar y permiten cambios fáciles más adelante.


Es extraño que diga que el código de escritura es más simple que manipular objetos en un entorno gráfico. Es una obviedad.
El diseñador está ahí para hacerte la vida más fácil y, a largo plazo, hace que tu código sea más fácil de mantener. Es más fácil buscar en el diseñador para ver cómo se ve su UI luego de leer el código e intentar imaginar cómo se vería.
Con Qt actual puedes hacer casi todo desde dentro del diseñador y las pocas cosas que no puedes hacer, puedes arreglarlo con muy pocas líneas de código en el constructor. Tomemos, por ejemplo, el ejemplo más simple: agregar una conexión de ranura de señal. Usar el diseñador es tan simple como hacer doble clic. Sin el diseñador, debe buscar la firma correcta de la señal, editar el archivo .h y luego editar escribir su código en el archivo .cpp. El diseñador le permite estar por encima de estos detalles y enfocarse en lo que realmente importa: la funcionalidad de su aplicación.


Es un post antiguo, pero les aconsejo que miren a Clementine, un reproductor de música que (creo) deriva de Amarok. Usan Qt4 y de lo que puedo ver hay una carpeta ui en la carpeta src del proyecto. En la carpeta ui como se podría esperar, tienen todo tipo de archivos .ui. Si compila e inicia Clementine, verá que la GUI es bastante compleja y bastante agradable.


Estamos usando Qt Designer si alguien necesita crear una Gui.
El objetivo es crear pequeños Widgets para ciertas tareas (como lo haría en un diseño de clase) y luego juntarlos en una "guía para padres".

De esta forma, sus widgets son altamente reutilizables y podrían usarse para Guis de forma modular. Solo tiene que especificar qué señales está enviando cada widget y qué ranuras ofrecen.

Además, estamos creando .ui-Files que podrían generarse durante el proceso de compilación. Hasta ahora no había necesidad de editar esos archivos a mano.


La organización para la que trabajo ha portado su aplicación GUI a Qt hace varios años. Creo que hay varios aspectos que vale la pena mencionar:

  • Trabajar con Qt Designer, al menos en ese momento, no era una opción realista: había demasiadas funciones que no se podían hacer con Qt Designer;
  • Las convenciones y la estructura que debía preservarse impedían el uso de Qt Designer;
  • Una vez que haya comenzado sin Designer, probablemente sea difícil volver a él;
  • el aspecto más importante, sin embargo, fue que los programadores estaban muy acostumbrados a programar usando vi o emacs, en lugar de usar un GUI IDE.

Mi propia experiencia, que se remonta aprox. 4 años, usando Qt3.3, es que el comportamiento dinámico en diálogos no fue posible de realizar en Designer.


Me gusta recurrir primero al diseñador para desarrollar widgets GUI. Como se menciona en las otras publicaciones, es más rápido. También recibe comentarios inmediatos para ver si "se ve bien" y no confunde al usuario. El diseñador es una de las principales razones por las que elijo Qt sobre otros kits de herramientas. Uso principalmente el diseñador para hacer los diálogos únicos.

Habiendo dicho eso, hago la ventana principal y cualquier widgets complejo a mano. Creo que esta es la intención de Trolltech. QFormLayout es una clase que proporcionan para crear fácilmente un diálogo de entrada programáticamente.

Por cierto, el diseñador en Qt 4 no es un IDE como el que tenían en Qt 3. Es solo un editor para editar archivos .ui. Me gusta de esa forma. El nuevo IDE multiplataforma se llamará Qt Creator.


Nuestra experiencia con Designer comenzó en Qt3.

Qt3

En ese momento, Designer fue útil principalmente para generar código que luego compilaría en su aplicación. Empezamos a usar para ese fin, pero con todo el código generado, una vez que lo edite, ya no podrá regresar y regenerarlo sin perder sus ediciones. Terminamos tomando el código generado y haciendo todo a mano de ahora en adelante.

Qt4

Qt4 ha mejorado significativamente en Designer. Ya no solo genera código, sino que puede cargar dinámicamente sus archivos de Designer (en xml) y conectarlos dinámicamente a los objetos en ejecución de su programa ; sin embargo, no hay código generado, debe nombrar los elementos en Designer y con los nombres para no romper tu código.

Mi evaluación es que no es tan útil como Interface Builder en Mac OS X, pero en este punto, pude ver el uso de los archivos de Designer directamente en un programa.

No hemos retrocedido al Diseñador desde Qt3, pero seguimos utilizándolo para prototipos y depuración de diseños.

Para tus problemas:

  1. Probablemente pueda salirse con la suya usando los diálogos estándar que ofrece Qt. QInputDialog o si subclases QDialog, asegúrate de utilizar QButtonDialogBox para asegurarte de que tus botones tengan el diseño de plataforma adecuado.

  2. Probablemente puedas hacer algo más limitado como xPad con funcionalidad limitada de Designer.

  3. No creo que puedas escribir algo como OpenOffice únicamente con Designer, pero quizás ese no sea el punto.

Utilizaría Designer como otra herramienta, como tu editor de texto. Una vez que encuentre las limitaciones, intente con una herramienta diferente para ese nuevo problema. Estoy totalmente de acuerdo con Steve S en que una de las ventajas de Designer es que alguien más que no sea programador puede hacer el diseño.


Para mí, depende de cuánta lógica está encapsulada en el widget / GUI. Si se trata de formularios simples, prefiero usar QtDesigner.

Si contiene controles complejos o interacción, tiendo a programarlo.


Solo para decir que he escrito y mantenido GUI complejas en Qt sin utilizar Qt Designer, no porque no me guste Qt Designer, sino porque nunca trabajé de esa manera.

Es en parte una cuestión de estilo y de dónde vienes: cuando comencé con Qt, tuve experiencias horribles con Dreamweaver y Frontpage y otras herramientas visuales de HTML, prefiriendo escribir código con HomeSite y recurriendo a Photoshop para obtener un diseño complicado. problemas.

Existe un peligro con IDEs de código visual que intenta mantener dentro de las herramientas visuales, pero también tiene que modificar el código, de una forma que no se comprende bien.

Aprendiendo el desarrollo de iPhone, por ejemplo, he encontrado frustrante golpear material visual ''mágico'' (''arrastre desde el círculo vacío en el inspector de Connections al objeto en la ventana Interface Builder ...'') que sería más simple (para yo) para entender en código simple.

Buena suerte con Qt: es un gran juego de herramientas, como sea que lo uses, y Qt Creator parece ser un gran IDE.


Uno de los principales beneficios del uso del diseñador para crear GUI es que otros programadores pueden cambiar o mantener formularios y widgets fácilmente sin la necesidad de profundizar en un código complejo.