¿Alguna alternativa práctica al modelo Signals + Slots para la programación GUI?

La mayoría de los kits de herramientas GUI actualmente usan el modelo Signals + Slots. Fueron Qt y GTK +, si no me equivoco, quién fue el pionero.

Ya sabes, los widgets u objetos gráficos (a veces incluso los que no se muestran) envían señales al controlador del bucle principal. El controlador del bucle principal llama a los eventos , devoluciones de llamada o ranuras asignadas para ese widget / objeto gráfico. Por lo general, hay virtualcontroladores de eventos predeterminados (y en la mayoría de los casos ) que ya proporciona el kit de herramientas para manejar todas las señales predefinidas, por lo tanto, a diferencia de los diseños anteriores, donde el desarrollador tenía que escribir todo el bucle principal y el controlador para cada mensaje. (piense en WINAPI), el desarrollador solo tiene que preocuparse por las señales en las que necesita implementar una nueva funcionalidad.

Ahora, hasta donde yo sé, este diseño se está utilizando en la mayoría de los juegos de herramientas modernos. Hay Qt, GTK +, FLTK, etc. Hay Java Swing. C # incluso tiene una función de lenguaje (eventos y delegados), y Windows Forms se ha desarrollado en este diseño. De hecho, durante la última década, este diseño para la programación GUI se ha convertido en una especie de estándar no escrito. Dado que aumenta la productividad y proporciona una mayor abstracción.

Sin embargo, mi pregunta es:

¿Existe algún diseño alternativo, que sea paralelo o práctico para la programación moderna de GUI?

¿Es el diseño de Señales + Tragamonedas, el único práctico en la ciudad? ¿Es factible hacer Programación GUI con cualquier otro diseño? ¿Hay algún juego de herramientas GUI moderno (preferiblemente exitoso y popular) basado en un diseño alternativo?

Aunque yo no diría que es todo lo que popular, no es siempre la programación reactiva para interfaces gráficas de usuario, especialmente la programación funcional reactivo , tal como se aplica, por ejemplo, por el marco Rx .NET , así como por varios conjuntos de herramientas de idiomas algo más esotéricos / plataformas , como reactivo-banana o FrTime , para Haskell y Racket respectivamente.

Esa es una de mis asignaturas favoritas, y durante aproximadamente una década (de los 70 a los 86) pensé que tener una GUI compuesta por objetos que respondieran a los eventos era la forma correcta de hacerlo.

Luego me topé con otra forma de hacerlo descrita aquí y con un proyecto de sourceforge aquí .

En pocas palabras, el problema con los objetos es que persisten, y si escribe código para crearlos, también tiene que escribir código para modificarlos gradualmente si se necesitan cambios, y de alguna manera obtener mensajes hacia y desde ellos. ¿No sería bueno si pudieras pintar lo que quisieras y luego volver a pintarlo si quieres algo diferente y no tener que preocuparte por la persistencia de objetos anteriores? ¿No sería bueno también si nunca tuvieras que escribir código para el manejo de mensajes, porque todo se hace bajo el capó?

Eso es lo que hace ese paquete. Para cuadros de diálogo simples, guarda un orden de magnitud en el código. Para diálogos complejos que cambian dinámicamente, los hace posibles.

PD: Solo he hecho esto para IU de escritorio y IU de terminal remoto, no para IU de navegador web. Estoy seguro de que es posible, pero no he tenido la oportunidad de probarlo.

Bueno, hay dos formas distintas de hacerlo:

1. Haga que cada widget exponga un mecanismo de suscripción granular (Señal / Ranura, Observador / Observable, Evento / Delegado) y haga que el código del cliente se suscriba y tome las medidas correspondientes.
2. Construyó un widget contra una abstracción de los datos que presenta y que el código del cliente implemente esa abstracción.

Aquí hay un ejemplo para el segundo enfoque:

interface Action {
     void execute();
     Bool isEnabled();
     Null<String> description();//used for tooltip
}
interface LabledAction extends Action {
     String getName();
}

Y ahora puede construir un código LabelButtoncontra LabledActiony un cliente puede simplemente implementarlo o usar alguna implementación predeterminada genérica, si está disponible y es adecuada.

En cierto modo, el segundo enfoque es menos flexible, pero más rígido. No solo conecta de alguna manera la vista con el modelo a través de medios relativamente atómicos. Usted diseña una GUI adecuada en función de sus requisitos y luego implementa los adaptadores entre esa GUI y la lógica de su dominio / aplicación.

Algunos sistemas de tipo de control utilizan un enfoque de base de datos: cada control de interfaz gráfica de usuario está vinculado a un archivo en la base de datos para que la interfaz gráfica de usuario siempre refleje el estado de la base de datos. Los ganchos de base de datos se utilizan para activar funciones cuando cambia un valor.