Classes / Tkinter

[Chad Netzer]

On Friday 10 January 2003 14:35, Newt wrote:
> Hi,
>
> 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?"

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
cnetzer at mail.arc.nasa.gov