Como eu coerentemente organizar módulos de uma aplicação desktop PyGTK?

Question

Eu estou trabalhando em um aplicativo de desktop em PyGTK e parecem estar esbarrando em algumas limitações da minha organização de arquivos. Até agora eu tenho estruturado meu projeto desta maneira:

• application.py - detém a classe de aplicativo principal (rotinas mais funcionais)
• gui.py - detém uma aplicação GTK gui baixo acoplamento. Alças sinalizar chamadas de retorno, etc.
• command.py - detém funções de automação de linha de comando não depende de dados na classe de aplicativo
• state.py - detém a classe estado de dados persistência

Este serviu muito bem até agora, mas neste momento application.py está começando a ficar um pouco longo. Eu olhei para inúmeras outras aplicações PyGTK e eles parecem ter problemas estruturais semelhantes. A certa altura do módulo começa primárias para ficar muito longa e não há maneira óbvia de quebrar o código em módulos mais estreitos sem sacrificar a orientação clareza e objeto.

Eu considerei fazer a GUI do módulo principal e ter módulos separados para as rotinas de barra de ferramentas, as rotinas de menus, etc, mas naquele momento eu acredito que vai perder a maior parte dos benefícios da OOP e acabar com um tudo referências -tudo cenário.

Eu deveria lidar com ter um módulo muito longo central ou há uma melhor forma de estruturar o projeto para que eu não tenho que confiar no navegador de classe tanto?

EDIT I ??

Ok, então ponto tomadas em relação a todo o material MVC. Eu tenho uma aproximação grosseira da MVC no meu código, mas é certo que eu provavelmente poderia ganhar alguma quilometragem por segregar ainda mais o modelo e controlador. No entanto, eu estou lendo sobre a documentação do python-gtkmvc (que é um grande achado, a propósito, obrigado por referência a ele) e minha impressão é que a sua não vai resolver o meu problema tanto como apenas formalizá-la. A minha aplicação é um único arquivo clareira, geralmente uma única janela. Portanto, não importa quão bem eu definir os papéis MVC dos módulos eu ainda vou ter um módulo de controlador de fazer quase tudo, o que é muito bonito o que eu tenho agora. É certo que eu estou um pouco confuso sobre a implementação MVC adequada e eu vou continuar pesquisando, mas não me parece esta arquitetura vai obter qualquer mais coisas fora do meu arquivo principal, é apenas vai mudar o nome que arquivo para controller.py.

Eu deveria estar pensando em separado Controller / Visualização de pares para seções separadas da janela (barra de ferramentas, os menus, etc)? Talvez isso é o que eu sinto falta aqui. Parece que este é o que S. Lott está se referindo em seu segundo ponto.

Obrigado pelas respostas até agora.

Answer 1

No projeto Wader usamos python gtkmvc , que faz muito mais fácil aplicar os padrões MVC ao usar pygtk e clareira, você pode ver a organização do nosso projeto de arquivo no svn repositório :

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

Answer 2

Isto tem provavelmente nada a ver com PyGTK, mas sim uma questão geral a organização de código. Você provavelmente se beneficiariam de aplicação de alguns padrões de projeto MVC (Model-View-Controller). Consulte Design Patterns , por exemplo.

Answer 3

"mantém a classe de aplicativo principal (a maioria das rotinas funcionais)"

Como no singular? - uma classe

Eu não estou surpreso que o Class One faz tudo O projeto não está funcionando. Pode não ser o que eu chamaria orientada a objetos. Não soa como ele segue o padrão de design típico MVC se a sua funcionalidade está se acumulando em uma única classe.

O que há nesta classe maciça? Eu sugiro que você provavelmente pode refatorar esta em pedaços. Você tem duas dimensões candidatos para refatorar seu classe de aplicação -. Se, na verdade, eu já adivinhou certo que você colocar tudo em uma única classe

1. Antes de fazer qualquer outra coisa, refatorar em componentes paralelos que as entidades do mundo real. Não está claro o que está em seu "state.py" - wether este é um modelo adequado de entidades do mundo real, ou mapeamentos apenas entre o armazenamento persistente e alguma estrutura de dados obscuros na aplicação. O mais provável é que você mover o processamento fora de sua aplicação e em seu modelo (possivelmente state.py, possivelmente, um novo módulo que é um modelo adequado.)

   Quebrar o modelo em partes. Ele vai ajudar a organizar os elementos de comando e de exibição. O erro mais comum MVC é colocar muito no controle e nada no modelo.

2. Mais tarde, uma vez que seu modelo está fazendo a maioria do trabalho, você pode olhar para refatorar em componentes paralelos que a apresentação GUI. Vários quadros de nível superior, por exemplo, provavelmente deve ter objetos cotrol separadas. Não está claro o que está em "GUI.py" - esta pode ser uma visão adequada. O que parece estar faltando é um componente de controle.

Answer 4

Desculpe a responder tão tarde. Kiwi me parece uma solução muito melhor do que gtkmvc. É minha primeira dependência para qualquer projeto pygtk.

Answer 5

Python 2.6 suporta importações relativos explícitas , que fazem uso de pacotes ainda mais fácil do que as versões anteriores. Eu sugiro que você olhar para quebrar a sua aplicação em módulos menores dentro de um pacote. Você pode organizar o seu pedido como este:

myapp/
  application/
  gui/
  command/
  state/

Onde cada diretório tem seu próprio __init__.py. Você pode ter um olhar para qualquer app python ou módulos de biblioteca mesmo padrão para exemplos.

Answer 6

Portanto, não tendo ouvido para trás em relação a minha edição para a pergunta original, eu fiz mais algumas pesquisas e a conclusão que parece estar chegando ao se que Sim , eu deve quebrar a interface para fora em vários vistas, cada um com seu próprio controlador. Python-gtkmvc fornece a capacidade para isso, fornecendo um parâmetro glade_top_widget_name para o construtor View. Isso tudo parece fazer uma boa dose de bom senso, embora ele vai exigir uma grande refatoração de minha base de código existente que eu pode ou não estar disposto a realizar no curto prazo (eu sei, eu sei, eu deveria . ) Além disso, eu estou à esquerda a se perguntar se deve ter apenas um único objeto Model (minha aplicação é bastante simples - não mais do que vinte e cinco estado vARs) ou se eu deveria quebrá-lo em vários modelos e tem que lidar com os controladores de observar vários modelos e acorrentar notificações através deles. (Mais uma vez, eu sei que realmente deve fazer o último.) Se alguém tiver qualquer outra visão, eu ainda realmente não sinto como se tivesse obtido uma resposta para a pergunta original, embora eu tenha um direção de cabeça agora.

(Além disso, parece que a sua deveria ser outras opções de arquitetura na mão, dado que até agora eu não tinha visto um único aplicativo Python codificado no estilo MVC, mas, novamente muitas aplicações Python tendem a ter o problema exato I 've descrito acima.)