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.
"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.

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.

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