He estado trabajando en el desarrollo de aplicaciones con muchos sistemas GUI "retenidos" (a continuación, más sobre lo que quiero decir con eso) como MFC, QT, Forms, SWING y varios marcos de GUI web hace algunos años. Siempre encontré los conceptos de la mayoría de los sistemas GUI demasiado complicados y torpes. La cantidad de eventos de devolución de llamada, oyentes, copias de datos, algo para encadenar a algo: las conversiones (y así sucesivamente) siempre fueron una fuente de errores y dolores de cabeza en comparación con otras partes de la aplicación. (Incluso con el uso "adecuado" de enlaces / modelos de datos).
Ahora estoy escribiendo juegos de computadora :). Trabajé con una GUI hasta ahora: Miyagi (no conocida, pero básicamente la misma Idea que todos los demás sistemas).
Fue horrible.
Para entornos de renderizado en tiempo real como Juegos, tengo la sensación de que los sistemas GUI "retenidos" son aún más obsoletos. Por lo general, las interfaces de usuario no necesitan tener un diseño automático o tener ventanas redimensionables sobre la marcha. En cambio, necesitan interactuar de manera muy eficiente con datos que cambian constantemente (como las posiciones 3D de modelos en el mundo)
Hace un par de años, me topé con "IMGUI", que es básicamente como un modo de gráficos inmediatos, pero para las interfaces de usuario. No presté demasiada atención, ya que todavía estaba en desarrollo de aplicaciones y la escena IMGUI en sí misma parecía no ser realmente amplia ni exitosa. Aún así, el enfoque que adoptan parece ser tan completamente sexy y elegante, que me hizo querer escribir algo para el próximo proyecto utilizando esta forma de interfaz de usuario (no logré convencer a nadie en el trabajo: (...)
permítanme resumir lo que quiero decir con "retenido" e "inmediato":
GUI retenida: en una fase de inicialización separada, crea "controles GUI" como etiquetas, botones, cuadros de texto, etc. y usa alguna forma descriptiva (o programática) de colocarlos en la pantalla, todo antes de que se muestre algo. Los controles contienen la mayor parte de su propio estado en la memoria, como ubicación X, Y, tamaño, bordes, controles secundarios, texto de etiqueta, imágenes, etc. Puede agregar devoluciones de llamada y escuchas para informarse de los eventos y actualizar los datos en el control de la GUI.
GUI inmediata: la biblioteca GUI consta de funciones "RenderButton", "RenderLabel", "RenderTextBox" ... de un solo disparo (editar: no se confunda con el Renderprefijo. Estas funciones también hacen la lógica detrás de los controles, como sondear la entrada del usuario, insertar caracteres, manejar la velocidad de repetición de caracteres cuando el usuario mantiene presionada una tecla y así sucesivamente ...) que puede llamar para representar "inmediatamente" un control (no no debe escribirse de inmediato en la GPU. Por lo general, se recuerda para el marco actual y se clasifica en lotes apropiados más adelante). La biblioteca no tiene ningún "estado" para estos. Si desea ocultar un botón ... simplemente no llame a la función RenderButton. Todas las funciones de RenderXXX que tienen interacción del usuario como botones o casillas de verificación tienen valores de retorno que indican si, por ejemplo, el usuario hizo clic en el botón. Entonces tu "RenderGUI" La función se ve como una gran función if / else donde llamas o no a tus funciones RenderXXX dependiendo del estado de tu juego y toda la lógica de actualización de datos (cuando se presiona un botón) se intermanga en el flujo. Todo el almacenamiento de datos está "fuera" de la interfaz gráfica de usuario y se pasa a pedido a las funciones de Render. (Por supuesto, dividiría las grandes funciones en varias o usaría algunas abstracciones de clase para agrupar partes de la interfaz gráfica de usuario. Ya no escribimos código como en 1980, ¿verdad?)
Ahora descubrí que Unity3D en realidad usa el mismo enfoque básico para sus sistemas GUI integrados. ¿Probablemente también haya un par de GUI con este enfoque?
Aún así ... al mirar alrededor, ¿parece haber un fuerte sesgo hacia los sistemas GUI retenidos? Al menos no he encontrado este enfoque, excepto en Unity3D y la comunidad IMGUI original parece ser bastante ... tranquila.
Entonces, ¿alguien trabajó con ambas ideas y tiene alguna opinión sólida?
Editar: Estoy más interesado en las opiniones que surgen de la experiencia del mundo real. Creo que hay muchas discusiones acaloradas en el foro IMGUI sobre cualquier "debilidad teórica" del enfoque inmediato de GUI, pero siempre encuentro más esclarecedor saber sobre las debilidades del mundo real .