¿Cómo organizo de manera coherente módulos para una aplicación de escritorio PyGTK?

Question

Estoy trabajando en una aplicación de escritorio en PyGTK y parecen estar chocando contra algunas limitaciones de mi organización de archivos. Hasta aquí hemos estructurado mi proyecto de esta manera:

• application.py - tiene la clase de aplicación primaria (rutinas más funcionales)
• gui.py - posee una aplicación GUI GTK débilmente acoplado. Maneja las devoluciones de llamada de señal, etc.
• command.py - mantiene las funciones de automatización de línea de comandos que no dependen de los datos de la clase de aplicación
• state.py - ejerce en la clase de persistencia de datos estatales

Esto ha servido bastante bien hasta el momento, pero en este punto, application.py está empezando a ser bastante largo. He examinado muchas otras aplicaciones PyGTK y parecen tener problemas estructurales similares. En cierto punto, el módulo primario comienza a ser muy largo y no hay una manera obvia de dividir el código en módulos más estrechos sin sacrificar la claridad y la orientación del objeto.

He considerado hacer de la GUI el módulo principal y tener módulos separados para las rutinas de la barra de herramientas, los menús, etc. referencias-todo escenario.

¿Debo tratar con tener un módulo central muy largo o hay una mejor manera de estructurar el proyecto de modo que no tengo que confiar en el navegador de clases tanto?

EDIT

Ok, por lo que el punto tomado con respecto a todas las cosas MVC. Tengo una aproximación aproximada de MVC en mi código, pero es cierto que probablemente podría obtener un poco de kilometraje segregando aún más el modelo y el controlador. Sin embargo, estoy leyendo la documentación de python-gtkmvc (que es un gran hallazgo por cierto, gracias por hacer referencia a ella) y mi impresión es que no va a resolver mi problema sino solo formalizarlo. Mi aplicación es un archivo de glade único, generalmente una sola ventana. Entonces, no importa cuán estrictamente defina los roles MVC de los módulos, todavía tendré un módulo de controlador haciendo casi todo, que es más o menos lo que tengo ahora. Es cierto que estoy un poco confuso sobre la implementación correcta de MVC y voy a seguir investigando, pero no me parece que esta arquitectura vaya a sacar más cosas de mi archivo principal, solo va a cambiar el nombre de esa arquitectura. archivo a controller.py

Debería estar pensando en Controlador/Ver pares separados para las secciones separadas de la ventana (la barra de herramientas, los menús, etc)? Tal vez eso es lo que me estoy perdiendo aquí. Parece que esto es a lo que se refiere S. Lott en su segundo punto.

Gracias por las respuestas hasta ahora.

Answer 1

En el proyecto Wader utilizamos python gtkmvc, que hace mucho más fácil aplicar los patrones MVC cuando se utiliza pygtk y claro, se puede ver la organización de los archivos de nuestro proyecto en el svn repository:

wader/ 
    cli/ 
    common/ 
    contrib/ 
    gtk/ 
    controllers/ 
    models/ 
    views/ 
    test/ 
    utils/ 

Answer 2

Esto tiene probablemente nada que ver con PyGTK, sino más bien una cuestión de la organización del código general. Probablemente se beneficiaría aplicando algunos patrones de diseño MVC (Modelo-Vista-Controlador). Ver Design Patterns, por ejemplo.

Answer 3

Python 2.6 soporta explicit relative imports, que hacen que el uso de paquetes aún más fácil que las versiones anteriores. Te sugiero que busques romper tu aplicación en módulos más pequeños dentro de un paquete. Puede organizar su aplicación como esta:

myapp/ 
    application/ 
    gui/ 
    command/ 
    state/ 

Donde cada directorio tiene su propio __init__.py. Puede echar un vistazo a cualquier aplicación de Python o incluso módulos de biblioteca estándar para ver ejemplos.

Answer 4

"mantiene el clase de aplicación primaria (la mayoría de las rutinas funcionales) "

Como en singular, ¿una clase?

No me sorprende que el diseño One Class Does Everything no funcione. Puede que no sea lo que llamaría orientado a objetos. No parece que siga el patrón de diseño típico de MVC si su funcionalidad se acumula en una sola clase.

¿Qué hay en esta clase masiva? Sugiero que probablemente puedas refactorizar esto en pedazos. Usted tiene dos dimensiones candidatas para refactorizar su clase de aplicación, si, de hecho, he adivinado bien que ha puesto todo en una sola clase.

1. Antes de hacer nada más, refactorícese en componentes que sean paralelos a las Entidades del mundo real. No está claro qué hay en tu "state.py": si este es un modelo adecuado de entidades del mundo real, o solo asignaciones entre el almacenamiento persistente y una estructura de datos turbia en la aplicación. Lo más probable es que transfiera el procesamiento de su aplicación a su modelo (posiblemente state.py, posiblemente un nuevo módulo que sea un modelo adecuado).

   Divida su modelo en pedazos. Ayudará a organizar el control y ver elementos. El error de MVC más común es poner demasiado control y nada en el modelo.

2. Más adelante, una vez que su modelo está haciendo la mayor parte del trabajo, puede ver el refactor en componentes que son paralelos a la presentación de la GUI. Varios marcos de nivel superior, por ejemplo, probablemente deberían tener objetos cotrol separados. No está claro qué hay en "GUI.py": esta podría ser una vista correcta. Lo que parece faltar es un componente de control.

Answer 5

Así no haber recibido respuesta con respecto a mi edición a la pregunta original, he hecho un poco más investigación y la conclusión me parece estar llegando a es que sí, que debe romper la interfaz a cabo en varias vistas , cada uno con su propio controlador. Python-gtkmvc proporciona la capacidad de esto proporcionando un parámetro glade_top_widget_name al constructor de Vista. Todo esto parece tener mucho sentido, aunque va a requerir una gran refacturación de mi código base existente que puedo o no estar dispuesto a asumir en el corto plazo (lo sé, lo sé, I debería.) Además, me pregunto si debería tener un solo objeto Model (mi aplicación es bastante simple, no más de veinticinco vars de estado) o si debería dividirla en varios modelos y lidiar con los controladores. observando múltiples modelos y encadenando notificaciones a través de ellos. (Una vez más, sé que realmente debería hacer esto último.) Si alguien tiene alguna idea adicional, todavía no siento que haya obtenido una respuesta a la pregunta original, aunque tengo una dirección para dirigirme ahora. .

(Además, parece que deberían tener otras opciones arquitectónicas, dado que hasta ahora no había visto una sola aplicación Python codificada en el estilo MVC, pero de nuevo muchas aplicaciones Python tienden a tener el problema exacto He descrito arriba.)

Answer 6

Lamento contestar tan tarde. Kiwi me parece una solución mucho mejor que gtkmvc. Es mi primera dependencia para cualquier proyecto pygtk.