Organizar una aplicación GUI

Question

Esta va a ser una pregunta genérica.

Tengo dificultades para diseñar una aplicación GUI, especialmente. al tratar con las interacciones entre las diferentes partes.

No sé cómo debo lidiar con el estado compartido. Por un lado, el estado compartido es malo, y las cosas deberían ser tan explícitas como sea posible. Por otro lado, no tener estado compartido introduce un acoplamiento no deseado entre los componentes.

Un ejemplo:

Quiero que mi solicitud sea extensible en una especie de Emacs/Vim de paso, a través de scripts. Claramente, algún tipo de estado compartido necesita ser modificado, para que la GUI lo use. Mi plan inicial era tener una "sesión" global accesible desde cualquier lugar, pero no estoy tan seguro de eso.

Una caso de uso complicado es la fijación de teclas. Quiero que el usuario pueda especificar combinaciones de teclas personalizadas a partir de un script. Cada combinación de teclas se correlaciona con un comando arbitrario, que recibe la sesión como único argumento.

Ahora, el componente del editor captura las pulsaciones de teclas. Tiene que tener acceso a las asignaciones de teclas, que son por sesión, por lo que necesita acceso a la sesión. ¿Es buena idea asociar el editor a la sesión? Otros componentes también necesitarán acceder a las combinaciones de teclas, por lo que ahora la sesión se comparte y puede ser un singleton ...

¿Hay alguna buena lectura sobre el diseño de aplicaciones GUI que vaya más allá de MVC?

Esto es Python y wxPython, FWIW.

[EDITAR]: Se agregó el uso de concreto.

Answer 1

Lamento saltar a esta pregunta tan tarde, pero nada, quiero decir nada puede vencer mirando el origen de una aplicación que hace algo similar. (Podría recomendar algo como http://pida.co.uk, pero hay muchos IDE de Pyx + Python extensibles, ya que suena como lo que estás haciendo).

Si se me permite hacer una pocas notas:

1. paso de mensajes no es intrínsecamente malo, y no necesariamente causa de acoplamiento entre los componentes, siempre y cuando los componentes se adhieren a las interfaces.

2. estado compartido no es intrínsecamente malo, pero me gustaría ir con tu instinto y utilizar lo menos posible. Dado que el universo en sí tiene estado, no puedes evitarlo por completo. Tiendo a usar un objeto "Boss" compartido que generalmente es una instancia única no única por aplicación, y es responsable de la intermediación de otros componentes.

3. Para combinaciones de teclas, tiendo a usar algún tipo de sistema de "Acción". Las acciones son cosas de alto nivel que un usuario puede hacer, por ejemplo: "Guardar el búfer actual", y se pueden representar convenientemente en la interfaz de usuario mediante botones de la barra de herramientas o elementos del menú. De modo que sus scripts/complementos crean acciones y las registran con algo central (por ejemplo, algún tipo de objeto de registro, consulte 1 y 2). Y su participación termina allí. Además de esto, tiene algún tipo de servicio de enlace de claves que mapea las teclas de las acciones (que enumera desde el registro, por sesión o de otro modo). De esta forma, ha logrado separar el plugin y el código de keybinding, la separación del editor y el código de acción. Como una ventaja adicional, su tarea de "Configurar accesos directos" o "Mapas de teclas definidos por el usuario" es especialmente fácil.

Podría seguir, pero la mayor parte de lo que tengo que decir es en el código base de PIDA, por lo que volver a mi punto original ...

Answer 2

Si ha mirado a MVC, probablemente se esté moviendo en la dirección correcta. MVC, MVP, vista pasiva, controlador de supervisión. Esas son todas formas diferentes, cada una con sus pros y contras, de lograr lo que estás buscando. Considero que la vista pasiva es el "ideal", pero hace que introduzcas demasiados widgets en tus interfaces GUI (es decir, en la interfaz). En general, encuentro que el Controlador Supervisor es un buen compromiso.

Answer 3

En MVC, la materia del modelo es el estado compartido de la información.

El elemento de control es el estado compartido de la configuración de control de la GUI y las respuestas a los clics del mouse y lo que no.

Su ángulo de secuencias de comandos puede

1) Actualización de los objetos del modelo. Esto es bueno. El Control puede ser "Observadores" de los objetos modelo y la Vista se puede actualizar para reflejar los cambios observados.

2) Actualice los objetos de control. Esto no es tan bueno, pero ... Los objetos de Control pueden realizar los cambios apropiados en el Modelo y/o la Vista.

No estoy seguro de cuál es el problema con MVC. ¿Podría proporcionar un ejemplo de diseño más detallado con problemas o inquietudes específicos?