How do I coherently organize modules for a PyGTK desktop application?

Question

I am working on a desktop application in PyGTK and seem to be bumping up against some limitations of my file organization. Thus far I've structured my project this way:

• application.py - holds the primary application class (most functional routines)
• gui.py - holds a loosely coupled GTK gui implementation. Handles signal callbacks, etc.
• command.py - holds command line automation functions not dependent on data in the application class
• state.py - holds the state data persistence class

This has served fairly well so far, but at this point application.py is starting to get rather long. I have looked at numerous other PyGTK applications and they seem to have similar structural issues. At a certain point the primary module starts to get very long and there is not obvious way of breaking the code out into narrower modules without sacrificing clarity and object orientation.

I have considered making the GUI the primary module and having seperate modules for the toolbar routines, the menus routines, etc, but at that point I believe I will lose most of the benefits of OOP and end up with an everything-references-everything scenario.

Should I just deal with having a very long central module or is there a better way of structuring the project so that I don't have to rely on the class browser so much?

EDIT I

Ok, so point taken regarding all the MVC stuff. I do have a rough approximation of MVC in my code, but admittedly I could probably gain some mileage by further segregating the model and controller. However, I am reading over python-gtkmvc's documentation (which is a great find by the way, thank you for referencing it) and my impression is that its not going to solve my problem so much as just formalize it. My application is a single glade file, generally a single window. So no matter how tightly I define the MVC roles of the modules I'm still going to have one controller module doing most everything, which is pretty much what I have now. Admittedly I'm a little fuzzy on proper MVC implementation and I'm going to keep researching, but it doesn't look to me like this architecture is going to get any more stuff out of my main file, its just going to rename that file to controller.py.

Should I be thinking about separate Controller/View pairs for seperate sections of the window (the toolbar, the menus, etc)? Perhaps that is what I'm missing here. It seems that this is what S. Lott is referring to in his second bullet point.

Thanks for the responses so far.

Answer 1

This has likely nothing to do with PyGTK, but rather a general code organization issue. You would probably benefit from applying some MVC (Model-View-Controller) design patterns. See Design Patterns, for example.

Answer 2

Python 2.6 supports explicit relative imports, which make using packages even easier than previous versions. I suggest you look into breaking your app into smaller modules inside a package. You can organize your application like this:

myapp/
  application/
  gui/
  command/
  state/

Where each directory has its own __init__.py. You can have a look at any python app or even standard library modules for examples.

Answer 3

In the project Wader we use python gtkmvc, that makes much easier to apply the MVC patterns when using pygtk and glade, you can see the file organization of our project in the svn repository:

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

Answer 4

"holds the primary application class (most functional routines)"

As in singular -- one class?

I'm not surprised that the One Class Does Everything design isn't working. It might not be what I'd call object-oriented. It doesn't sound like it follows the typical MVC design pattern if your functionality is piling up in a single class.

What's in this massive class? I suggest that you can probably refactor this into pieces. You have two candidate dimensions for refactoring your application class -- if, indeed, I've guessed right that you've put everything into a single class.

1. Before doing anything else, refactor into components that parallel the Real World Entities. It's not clear what's in your "state.py" -- wether this is a proper model of real-world entities, or just mappings between persistent storage and some murky data structure in the application. Most likely you'd move processing out of your application and into your model (possibly state.py, possibly a new module that is a proper model.)

   Break your model into pieces. It will help organize the control and view elements. The most common MVC mistake is to put too much in control and nothing in the model.

2. Later, once your model is doing most of the work, you can look at refactor into components that parallel the GUI presentation. Various top-level frames, for example, should probably have separate cotrol objects. It's not clear what's in "GUI.py" -- this might be a proper view. What appears to be missing is a Control component.

Answer 5

So having not heard back regarding my edit to the original question, I have done some more research and the conclusion I seem to be coming to is that yes, I should break the interface out into several views, each with its own controller. Python-gtkmvc provides the ability to this by providing a glade_top_widget_name parameter to the View constructor. This all seems to make a good deal of sense although it is going to require a large refactoring of my existing codebase which I may or may not be willing to undertake in the near-term (I know, I know, I should.) Moreover, I'm left to wonder whether should just have a single Model object (my application is fairly simple--no more than twenty-five state vars) or if I should break it out into multiple models and have to deal with controllers observing multiple models and chaining notifications across them. (Again, I know I really should do the latter.) If anyone has any further insight, I still don't really feel like I've gotten an answer to the original question, although I have a direction to head in now.

(Moreover it seems like their ought to be other architectural choices at hand, given that up until now I had not seen a single Python application coded in the MVC style, but then again many Python applications tend to have the exact problem I've described above.)

Answer 6

Sorry to answer so late. Kiwi seems to me a far better solution than gtkmvc. It is my first dependency for any pygtk project.