[Tutor] working with Tkinter

Jeff Shannon jeff@ccvcorp.com
Thu, 25 Apr 2002 10:45:55 -0700


> Maximiliano Ichazo <max_ig@yahoo.com> wrote:
>
> I'm working out a small program with Tkinter that has an initial dialog
> with many buttons calling many dialogs with many buttons calling more
> dialogs.
>
> My problem is about the code, it looks like spaghetti. I would like to
> hear some advice re how to organize code preventing spaghetti-like
> programming.

I'm not overly familiar with Tkinter, but this is really more about general design than it is about Tkinter, so feel free to ignore
anything Tkinter-specific that I say and just pay attention to the general intent, here.  ;)

The first thing to do, is to try to make your program as modular as possible.  This means breaking it up into small, independent
chunks.  In your case, since you seem to be using lots of special dialogs, the most obvious choice for how to break things up is to
make each dialog a separate unit.

The first thing to do, is to make sure that each dialog is represented by a separate class.  It's probably even a good idea to put
each one into a separate .py file.  Any information that you need to set up the dialog, should be passed in as an argument to its
__init__() method.  Try to make each dialog as independent as possible.  Since you are (presumably) already grouping everything on
the dialogs so that they make sense to the user (everything to do 'foo' on one dialog, everything to do 'bar' on another, etc), it
shouldn't be *too* hard to make the code for each dialog relatively independent too.  Keep in mind that, while a given dialog is
being shown, it's probably the *only* thing that the user is looking at, so you can consider that dialog to be the entire
application for that moment.  Each dialog has a purpose, and you can focus on *just* that purpose while coding that dialog --
whether that purpose is "write some selected information into the database" or "set various options for the parent dialog", you can
(mostly) ignore any other considerations while that dialog is up.

This way, when you have a button that should pull up another dialog, you can simply create an instance of the subdialog class and
run its DoModal() method (or whatever Tkinter uses).  Once *that* method returns, you can gather any changed settings from the
subdialog (if applicable) and then destroy it (often by just returning from the button's OnClick() handler).

Hope this makes some sense -- if not, feel free to ask more specific questions.  :)

Jeff Shannon
Technician/Programmer
Credit International