GUI del código de mano o use la herramienta de diseño de GUI

Question

Me gustaría escuchar algunas opiniones sobre la codificación manual de sus GUI, como suele hacerse al usar Java o Qt con C++, frente a una herramienta de diseño de interfaz gráfica de usuario. Ejemplos de herramientas de diseñador de GUI serían MFC GUI-designer, Qt designer, Interface Builder (Apple).

Solía ​​ser un fanático de la codificación manual, pero de experiencia reciente he cambiado. El problema que he visto con la codificación manual es que es bastante rápido y flexible escribir las GUI, pero una vez que necesita hacer un cambio en una GUI escrita hace mucho tiempo puede ser muy difícil. Encontrar el elemento correcto en un panel grande puede ser difícil.

El segundo problema es que hace que sea demasiado fácil agregar mucha lógica en la creación de la GUI y el código de diseño. A menudo tuve que asumir el mantenimiento del código GUI, que es muy difícil de reutilizar porque su comportamiento se mezcla con su apariencia y el diseño y el comportamiento de la mezcla a menudo hace que la clase sea muy grande y difícil de entender.

El uso de una herramienta de diseño de interfaz gráfica de usuario obliga a una separación mucho más clara entre la apariencia y la lógica en mi opinión.

Answer 1

Creo firmemente que debe utilizar un constructor de interfaz en lugar de codificar manualmente una GUI. Como en la pregunta mencionada, es una separación mucho más clara y una vez que algo tiene que editarse es mucho más fácil.

El Qt Designer tiene esta función para crear una clase de un archivo .ui ₁₎, pero creo que no usar esta característica es la mejor manera, ya que esto crea sólo más codificado que no debería existir en absoluto . El problema de velocidad de crear la ventana desde un archivo .ui es insignificante porque la ventana debe cargarse solo una vez.

Esta es PyQt, pero es posible algo similar en C++:

class SelectDateDialog(QDialog): 
    def __init__(self): 
     QDialog.__init__(self) 
     uic.loadUi("resources/SelectDate.ui", self) 

Esencialmente, esto tiene el mismo efecto que incluyendo toda la interfaz de usuario de código en el método __init__(), pero la interfaz de usuario está casi completamente separada de la código.

¹⁾.ui archivos son archivos XML que describen una interfaz de usuario

Answer 2

Depende de la situación, realmente. Creo que ambos tienen su lugar, y suelo usar un enfoque híbrido.

Siempre hay algunas cosas que el constructor de la GUI no puede hacer (por ejemplo, establecer el color en una constante de UIColor en el Creador de interfaces). Por otro lado, la mayor parte del trabajo de UI es bastante mundano (por ejemplo, agregar etiquetas estáticas).

Prefiero hacer las cosas mundanas en el constructor de GUI, y las cosas más interesantes en el código.

Además, de vez en cuando me encuentro editando a mano el XML producido por el constructor de la GUI (Interface Builder y glade en mi caso).

Answer 3

Es bastante gracioso que haya sido al revés para mí. Hablando desde la perspectiva de Winforms, el código generado por el diseñador es bastante ruidoso, con tal vez la cuarta parte o la mitad de todas las configuraciones de propiedad realmente necesarias. Hacer controles bastante grandes también es más una tentación cuando se trabaja con un diseñador. Cambiar la jerarquía de controles en el diseñador de Winforms es una pesadilla para mí.

En mi último proyecto, he creado API adicionales para configurar divisores en formularios, dockmanagers, menús, barras de herramientas, etc. de manera declarativa. Estos son tales que harán cumplir más la separación de las preocupaciones.

También trato de confiar mucho más en las características de diseño automático que, sin duda, son mucho mejores en WPF, pero también pueden ser útiles en Windows Forms.

Answer 4

Mi opinión sobre esto: 1. código de interfaz gráfica de usuario a mano codificado es mucho más reutilizable 2. problemas de diseño son más simples con los diseñadores

Answer 5

Yo aconsejaría fuertemente para utilizar el Interface Builder en OS X. Si lo hace por La mano está bien si quieres aprender, pero te ahorrarás muchos dolores de cabeza utilizándola en proyectos reales. Realmente es bastante poderoso.

En cuanto a Java y C++, depende de lo que esté haciendo y en qué plataformas. Para aplicaciones simples, puede salirse con la suya sin ver el código de UI. Sin embargo, para aplicaciones complicadas y clientes ricos, normalmente debe hacer parte del código manualmente.

Answer 6

Me siempre codificar manualmente el diseño GUI, donde no existe un estándar (o de-facto estándar) idioma de la interfaz de marcado (como con Java). La razón de esto es que he encontrado que utilizar una herramienta de diseño de constructores de GUI lo vinculará a usar un IDE particular. Con el tiempo, el mejor IDE para el diseño de la GUI y/o código de escritura cambiará y cada desarrollador debe poder elegir libremente el IDE con el que se sienta más cómodo con.

Donde trabajo actualmente, tenemos muchas GUI heredadas que fueron escritas usando el constructor de GUI NetbeansMatisse (contra mi consejo en ese momento :-). Estos ahora casi no se pueden mantener porque todos los desarrolladores prefieren IntelliJ IDEA o Eclipse como su IDE. No es realista ni factible que los desarrolladores activen Netbeans solo para modificar el diseño de la GUI (las personas no mantienen las definiciones del proyecto de Netbeans sincronizadas, etc.).

Otro punto es que el tiempo total de escritura del código de disposición de la GUI es probablemente solo el 5% del esfuerzo total de desarrollo de un proyecto determinado. Incluso si le lleva el doble de tiempo escribir el código usted mismo, esto no se traduce en una sobrecarga en el gran esquema de cosas. Y es un precio pequeño a pagar por la capacidad de mantenimiento a largo plazo.

Siempre que tenga claro acerca de separar la lógica de diseño de la GUI de la lógica comercial, no creo que algo sufra como resultado. ¡Aquí nadie usa constructores de GUI!

Answer 7

Lo hago a mano, es mucho más fácil mezclar cosas y reutilizar paneles dentro de la aplicación (algunos paneles pueden aparecer en varios lugares).

Al usar un diseñador funciona cuando estás en un equipo, se supone que los artistas hacen la GUI.

Encontrar el elemento correcto en el panel grande puede ser difícil.

?? Nunca he visto eso.

Answer 8

Tiendo a pensar que la respuesta correcta depende de la cultura de la plataforma de destino. En OS X, Interface Builder es una parte tan integral de la cadena de herramientas que es difícil evitarlo.

En Java (awt o swing), el reverso es realmente cierto. No hay soporte de herramientas para esto.

Realmente, la forma en que puede ver, es la forma en que las herramientas producen sus resultados. Interface Builder produce archivos de formato .nib que son específicos de la forma en que Cocoa pone controles en la pantalla. Entiende lo que es esencialmente un formato de marcado de interfaz. Java no tiene un concepto similar. Todo es una clase compilada, y por eso es mucho más difícil obtener resultados convenientes.

GTK +, cuando se combina con glade, parece lograr un equilibrio razonable entre los dos.

Answer 9

Nada impide mezclar los dos enfoques. A menudo hago el diseño principal de un formulario en un diseñador de GUI (porque es rápido y ves lo que estás haciendo), y colocas uno o más paneles que luego se rellenan con código. Esto es especialmente útil cuando la GUI se debe adaptar a situaciones específicas, por ejemplo, si la GUI debe cambiar de acuerdo con qué hardware está conectado.

En cualquier caso, lo más importante es mantener separadas la GUI y la lógica de la aplicación.

Answer 10

codificación manual puede ser bueno si quieres algunas características no estándar que incluyen en la interfaz de usuario. Tiene más flexibilidad, pero necesitará invertir más tiempo para crear una buena interfaz, ya que Java/C++ no son un lenguaje para designar el diseño de la interfaz de usuario.

En el más, si tiene un control de revisión puede ver el historial de cambios, algo que no se puede hacer con un diseño que utiliza un formato binario, o un formato xml que no es compatible con RCS.

Hoy en día, la mayoría de las herramientas disponibles para diseñar visualmente una interfaz de usuario carecen de algunas características. No son lo suficientemente flexibles, algunas características solo se pueden lograr codificándolas. Además, en algunos casos, el código generado no es realmente amigable para los humanos, y si lo modifica a mano, es posible que ya no pueda seguir usando el diseñador.

Pero el diseño puede ser realmente un ahorro de tiempo si el diseño es simple, y podemos esperar que los diseñadores mejoren en el futuro, pero no lo voy a sostener por amplitud.

Mi conclusión es que si necesita flexibilidad hoy tendrá que codificar manualmente la interfaz, si quiere algo simple y rápido, el diseñador es la mejor opción.

Quizás en el futuro los diseñadores serán más potentes, o tal vez habrá nuevos lenguajes especializados en el diseño de la interfaz de usuario que serán más adecuados para su uso en C++/Java, algo así como XUL o XAML.

Answer 11

Si está diseñando una aplicación comercial con muchos formularios de entrada y datos tabulares, escribir código para su UI es más rápido y más fácil de mantener que usar un diseñador de interfaz de usuario. En ese tipo de aplicaciones, casi nunca es necesario colocar con precisión un elemento en un lugar predefinido en la pantalla, mientras que, por otro lado, hay una gran cantidad de convenciones de repetición y diseño que pueden extraerse simplemente en métodos separados.

Tome por ejemplo un diálogo de preferencias de Eclipse o OpenOffice. Hay un montón de categorías y un conjunto de diferentes opciones para cada una. Si tiene que hacer algo de ese tamaño, diseñar manualmente cada pantalla es una tarea mundana. Un enfoque mucho mejor es escribir código que genere elementos de IU sobre la marcha, a partir de datos de dominio proporcionados, de acuerdo con algunas convenciones y valores predeterminados.

No veo cómo el uso de un diseñador facilita una mejor separación, ni cómo esa separación percibida ayudaría con nada, dado que ya mantiene su lógica comercial fuera de la interfaz de usuario.

Y, finalmente, si está utilizando Java, asegúrese de consultar MigLayout. Funciona con Swing y SWT, su sintaxis es muy concisa y clara, y tiene un modo de depuración que es increíblemente útil.