Intermezzo

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
• a little bit of data verification – that true/false values remain true or false (extra points would be to use a RadioButton widget)
• backing up the existing file and
• writing data that we’ve collected to the file

Some Notes

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.

In the meantime I will think about the tutorials to come.