Ooops, sorry. What was going to be a short respite after Easter became a rather extended vacation.

The good news is that, we’ve finally done enough to pretty much do any application you want (excepting, perhaps, graphical games). The bad news is that I’m in a quandry about whether to fill out a few holes in the basics (which can be done in bite size chunks), or move onto more advanced stuff (like pygame, which is definitely on the menu). Not so much a problem for this lesson though – it’s a review of where we’re up to.

I have also started putting together an index, which I am slowly catching up on. If you’re looking for a particular topic that I’ve covered, try the Index (although it’s not yet complete).

Recap

So, what’s the recap on what we’ve done recently?

In our past few tutorials we have created our own GUI application which actually does something useful (more or less). Some of the things we covered are:

configuration files

parsing (that is, breaking data down into pieces that our program can make sense of)

we had a specific example of using instances of a class to store each configuration item

we read a configuration file and parsed it

we got to see some new widgets: Tkinter TextEdit, Entry and Frame widgets

we saw how to use a Tkinter Frame Widget as a way of collecting a group of related widgets together (don’t be scared of using Frames to help layout things correctly. In some layouts you can have heaps of Frames)

we have tested a layout with a single row of widgets before generalising it for every widget[* see the process point below]

subclassing our original widget to add some GUI related functionality

why widgets are not like variables and how to get the letters currently in the Entry widget

Of these, I wanted to point out the process item. that is, testing a layout with a single row of widgets first. It is generally a good idea to break down any problem that you’re faced with into a number of smaller subtasks before solving the subtasks one after another. At the time, this will seem tedious because in your mind you want to solve the big issue, not some small issue. However, it’s the best way to (not only) actually reach a solution, (but also) to reach a solution which you can reuse in the future. Often, trying to solve the larger task in one go will end up either in failure because it’s too complex (at which time you’re forced to break it up into subtasks anyway), or with a solution which is so specific to your circumstances that it can’t be reused. Take the extra time to break down the task.