Classes / Tkinter
Newt
I'm putting together an application that consists of one main 'window',
visible all the time, and six or seven other 'windows', each of which would
be displayed once.
At the moment, each 'window' has been put into it's own class, together with
all it's needed individual functions (e.g. data entry checking etc).
My query is "is this appropriate for an application of this type?"
TIA
Newt
Chad Netzer
Maybe. Maybe not. How much to you intend for this application to
"scale"? also, how similar are the 'windows' (I don't mean just GUI
layout, I mean conceptually similar in what services the provide to the
core of your software)?
I really should write an organized essay on this (with regard to
Tkinter and Python), but for now, here are my rambling suggestions.
Basically, you should remember this:
- You can use subclassing to extend the interface of objects, and to
reuse implementation. But you should avoid using it JUST to reuse
implementation.
- You need to know what services your software will provide to the
user, and then you need to design classes that have an interface to
provide those services (forget the GUI for this part). Use inheritence
to extend the API (but don't use it to remove large parts of the API,
just becuase you want to reuse a small part of it. An inherited object
"is" she tame kind of object as it's parent.
- Use small communicating objects to provide common services, and
incorporate them into your "windows". Do not inherit them, just make
them and use them (aggregation, not inheritance).
- Once you have thought about what your program really needs to do,
only then start thinking about the GUI interface. It should follow the
program, not define it.
- Separate the logic of your design (what you want the program to
do) from the interface. It is a cardinal sin of GUI scalability to
incorporate the state and services of the software wholly in the user
interface. You will go mad from it eventually. Basically, the GUI
gets input from the user, it provides output to the user, and it should
communicate to your program which is implementing your algorithm.
Preferably there is a lyer between the too. Search Google for talk
about "Model-View-Presenter" architecture (or the similar, but I think
deprecated, "Model-View-Controller"). Do this NOW! :)
Okay, in practical terms what does that all mean?
Assuming Tkinter, don't just start inheriting from Frame to make
windows, then adding all kinds of widgets which are inherited from
other widgets, and then having a million callbacks to calculate and
update each other when input changes.
Instead, have a core program. Each window communicates with the core,
and the core comminicates back to those windows. The windows do NOT
communicate with each other, or to the various parts of themselves (by
and large).
Ask yourself, "if I want to quit, and later restart my program, with
everything exactly like it is (on the GUI), how would I do it?" Or, "I
want to be able to 'script' my program, without interacting with the
GUI. How will I do it?"
Also, by all means, look at dispatcher.py, by Patrick O'Brien, from the
Python cookbook. Consider using it instead of having tons and tons of
callback driven event processing.
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov