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.
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.)
How do I coherently organize modules for a PyGTK desktop application?