Let’s put some of these canned dialogs to better use. Example 8-7 implements an attachable Quit button that uses standard dialogs to verify the quit request. Because it’s a class, it can be attached and reused in any application that needs a verifying Quit button. Because it uses standard dialogs, it looks as it should on each GUI platform.

"""
a Quit button that verifies exit requests;
to reuse, attach an instance to other GUIs, and re-pack as desired
"""

from tkinter import *                          # get widget classes
from tkinter.messagebox import askokcancel     # get canned std dialog

class Quitter(Frame):                          # subclass our GUI
    def __init__(self, parent=None):           # constructor method
        Frame.__init__(self, parent)
        self.pack()
        widget = Button(self, text='Quit', command=self.quit)
        widget.pack(side=LEFT, expand=YES, fill=BOTH)

    def quit(self):
        ans = askokcancel('Verify exit', "Really quit?")
        if ans: Frame.quit(self)

if __name__ == '__main__':  Quitter().mainloop()

This module is mostly meant to be used elsewhere, but it puts up the button it implements when run standalone. Figure 8-10 shows the Quit button itself in the upper left, and the askokcancel verification dialog that pops up when Quit is pressed.

Figure 8-10. Quitter, with askokcancel dialog

If you press OK here, Quitter runs the Frame quit method to end the GUI to which this button is attached (really, the mainloop call). But to really understand how such a spring-loaded button can be useful, we need to move on and study a client GUI in the next section.

So far, we’ve seen a handful of standard dialogs, but there are quite a few more. Instead of just throwing these up in dull screenshots, though, let’s write a Python demo script to generate them on demand. Here’s one way to do it. First of all, in Example 8-8 we write a module to define a table that maps a demo name to a standard dialog call (and we use lambda to wrap the call if we need to pass extra arguments to the dialog function).

# define a name:callback demos table

from tkinter.filedialog   import askopenfilename        # get standard dialogs
from tkinter.colorchooser import askcolor               # they live in Lib	kinter
from tkinter.messagebox   import askquestion, showerror
from tkinter.simpledialog import askfloat

demos = {
    'Open':  askopenfilename,
    'Color': askcolor,
    'Query': lambda: askquestion('Warning', 'You typed "rm *"
Confirm?'),
    'Error': lambda: showerror('Error!', "He's dead, Jim"),
    'Input': lambda: askfloat('Entry', 'Enter credit card number')
}

I put this table in a module so that it might be reused as the basis of other demo scripts later (dialogs are more fun than printing to stdout). Next, we’ll write a Python script, shown in Example 8-9, which simply generates buttons for all of this table’s entries—use its keys as button labels and its values as button callback handlers.

"create a bar of simple buttons that launch dialog demos"

from tkinter import *              # get base widget set
from dialogTable import demos      # button callback handlers
from quitter import Quitter        # attach a quit object to me

class Demo(Frame):
    def __init__(self, parent=None, **options):
        Frame.__init__(self, parent, **options)
        self.pack()
        Label(self, text="Basic demos").pack()
        for (key, value) in demos.items():
            Button(self, text=key, command=value).pack(side=TOP, fill=BOTH)
        Quitter(self).pack(side=TOP, fill=BOTH)

if __name__ == '__main__': Demo().mainloop()

This script creates the window shown in Figure 8-11 when run as a standalone program; it’s a bar of demo buttons that simply route control back to the values of the table in the module dialogTable when pressed.

Figure 8-11. demoDlg main window

Notice that because this script is driven by the contents of the dialogTable module’s dictionary, we can change the set of demo buttons displayed by changing just dialogTable (we don’t need to change any executable code in demoDlg). Also note that the Quit button here is an attached instance of the Quitter class of the prior section whose frame is repacked to stretch like the other buttons as needed here—it’s at least one bit of code that you never have to write again.

This script’s class also takes care to pass any **options constructor configuration keyword arguments on to its Frame superclass. Though not used here, this allows callers to pass in configuration options at creation time (Demo(o=v)), instead of configuring after the fact (d.config(o=v)). This isn’t strictly required, but it makes the demo class work just like a normal tkinter frame widget (which is what subclassing makes it, after all). We’ll see how this can be used to good effect later.

We’ve already seen some of the dialogs triggered by this demo bar window’s other buttons, so I’ll just step through the new ones here. Pressing the main window’s Query button, for example, generates the standard pop up in Figure 8-12.

Figure 8-12. demoDlg query, askquestion dialog

This askquestion dialog looks like the askyesno we saw earlier, but actually it returns either string "yes" or "no" (askyesno and askokcancel return True or False instead—trivial but true). Pressing the demo bar’s Input button generates the standard askfloat dialog box shown in Figure 8-13.

Figure 8-13. demoDlg input, askfloat dialog

This dialog automatically checks the input for valid floating-point syntax before it returns, and it is representative of a collection of single-value input dialogs (askinteger and askstring prompt for integer and string inputs, too). It returns the input as a floating-point number object (not as a string) when the OK button or Enter key is pressed, or the Python None object if the user clicks Cancel. Its two relatives return the input as integer and string objects instead.

When the demo bar’s Open button is pressed, we get the standard file open dialog made by calling askopenfilename and captured in Figure 8-14. This is Windows 7’s look-and-feel; it can look radically different on Macs, Linux, and older versions of Windows, but appropriately so.

Figure 8-14. demoDlg open, askopenfilename dialog

A similar dialog for selecting a save-as filename is produced by calling asksaveasfilename (see the Text widget section in Chapter 9 for a first example). Both file dialogs let the user navigate through the filesystem to select a subject filename, which is returned with its full directory pathname when Open is pressed; an empty string comes back if Cancel is pressed instead. Both also have additional protocols not demonstrated by this example:

Another common dialog call in the tkinter filedialog module, askdirectory, can be used to pop up a dialog that allows users to choose a directory rather than a file. It presents a tree view that users can navigate to pick the desired directory, and it accepts keyword arguments including initialdir and title. The corresponding Directory object remembers the last directory selected and starts there the next time the dialog is shown.

We’ll use most of these interfaces later in the book, especially for the file dialogs in the PyEdit example in Chapter 11, but feel free to flip ahead for more details now. The directory selection dialog will show up in the PyPhoto example in Chapter 11 and the PyMailGUI example in Chapter 14; again, skip ahead for code and screenshots.

Finally, the demo bar’s Color button triggers a standard askcolor call, which generates the standard color selection dialog shown in Figure 8-15.

Figure 8-15. demoDlg color, askcolor dialog

If you press its OK button, it returns a data structure that identifies the selected color, which can be used in all color contexts in tkinter. It includes RGB values and a hexadecimal color string (e.g., ((160, 160, 160), '#a0a0a0')). More on how this tuple can be useful in a moment. If you press Cancel, the script gets back a tuple containing two nones (Nones of the Python variety, that is).

The dialog demo launcher bar displays standard dialogs and can be made to display others by simply changing the dialogTable module it imports. As coded, though, it really shows only dialogs; it would also be nice to see their return values so that we know how to use them in scripts. Example 8-10 adds printing of standard dialog results to the stdout standard output stream.

"""
similar, but show return values of dialog calls;  the lambda saves data from
the local scope to be passed to the handler (button press handlers normally
get no arguments, and enclosing scope references don't work for loop variables)
and works just like a nested def statement: def func(key=key): self.printit(key)
"""

from tkinter import *              # get base widget set
from dialogTable import demos      # button callback handlers
from quitter import Quitter        # attach a quit object to me

class Demo(Frame):
    def __init__(self, parent=None):
        Frame.__init__(self, parent)
        self.pack()
        Label(self, text="Basic demos").pack()
        for key in demos:
            func = (lambda key=key: self.printit(key))
            Button(self, text=key, command=func).pack(side=TOP, fill=BOTH)
        Quitter(self).pack(side=TOP, fill=BOTH)

    def printit(self, name):
        print(name, 'returns =>', demos[name]())     # fetch, call, print

if __name__ == '__main__': Demo().mainloop()

This script builds the same main button-bar window, but notice that the callback handler is an anonymous function made with a lambda now, not a direct reference to dialog calls in the imported dialogTable dictionary:

# use enclosing scope lookup
func = (lambda key=key: self.printit(key))

We talked about this in the prior chapter’s tutorial, but this is the first time we’ve actually used lambda like this, so let’s get the facts straight. Because button-press callbacks are run with no arguments, if we need to pass extra data to the handler, it must be wrapped in an object that remembers that extra data and passes it along, by deferring the call to the actual handler. Here, a button press runs the function generated by the lambda, an indirect call layer that retains information from the enclosing scope. The net effect is that the real handler, printit, receives an extra required name argument giving the demo associated with the button pressed, even though this argument wasn’t passed back from tkinter itself. In effect, the lambda remembers and passes on state information.

Notice, though, that this lambda function’s body references both self and key in the enclosing method’s local scope. In all recent Pythons, the reference to self just works because of the enclosing function scope lookup rules, but we need to pass key in explicitly with a default argument or else it will be the same in all the generated lambda functions—the value it has after the last loop iteration. As we learned in Chapter 7, enclosing scope references are resolved when the nested function is called, but defaults are resolved when the nested function is created. Because self won’t change after the function is made, we can rely on the scope lookup rules for that name, but not for loop variables like key.

In earlier Pythons, default arguments were required to pass all values in from enclosing scopes explicitly, using either of these two techniques:

# use simple defaults
func = (lambda self=self, name=key: self.printit(name))

# use a bound method default
func = (lambda handler=self.printit, name=key: handler(name))

Today, we can get away with the simpler enclosing -scope reference technique for self, though we still need a default for the key loop variable (and you may still see the default forms in older Python code).

Note that the parentheses around the lambdas are not required here; I add them as a personal style preference just to set the lambda off from its surrounding code (your mileage may vary). Also notice that the lambda does the same work as a nested def statement here; in practice, though, the lambda could appear within the call to Button itself because it is an expression and it need not be assigned to a name. The following two forms are equivalent:

for (key, value) in demos.items():
    func = (lambda key=key: self.printit(key))          # can be nested i Button()

for (key, value) in demos.items():
    def func(key=key): self.printit(key)                # but def statement cannot

You can also use a callable class object here that retains state as instance attributes (see the tutorial’s __call__ example in Chapter 7 for hints). But as a rule of thumb, if you want a lambda’s result to use any names from the enclosing scope when later called, either simply name them and let Python save their values for future use, or pass them in with defaults to save the values they have at lambda function creation time. The latter scheme is required only if the variable used may change before the callback occurs.

When run, this script creates the same window (Figure 8-11) but also prints dialog return values to standard output; here is the output after clicking all the demo buttons in the main window and picking both Cancel/No and then OK/Yes buttons in each dialog:

C:...PP4EGuiTour> python demoDlg-print.py
Color returns => (None, None)
Color returns => ((128.5, 128.5, 255.99609375), '#8080ff')
Query returns => no
Query returns => yes
Input returns => None
Input returns => 3.14159
Open returns =>
Open returns => C:/Users/mark/Stuff/Books/4E/PP4E/dev/Examples/PP4E/Launcher.py
Error returns => ok

Now that I’ve shown you these dialog results, I want to next show you how one of them can actually be useful.

The standard color selection dialog isn’t just another pretty face—scripts can pass the hexadecimal color string it returns to the bg and fg widget color configuration options we met earlier. That is, bg and fg accept both a color name (e.g., blue) and an askcolor hex RGB result string that starts with a # (e.g., the #8080ff in the last output line of the prior section).

This adds another dimension of customization to tkinter GUIs: instead of hardcoding colors in your GUI products, you can provide a button that pops up color selectors that let users choose color preferences on the fly. Simply pass the color string to widget config methods in callback handlers, as in Example 8-11.

from tkinter import *
from tkinter.colorchooser import askcolor

def setBgColor():
    (triple, hexstr) = askcolor()
    if hexstr:
        print(hexstr)
        push.config(bg=hexstr)

root = Tk()
push = Button(root, text='Set Background Color', command=setBgColor)
push.config(height=3, font=('times', 20, 'bold'))
push.pack(expand=YES, fill=BOTH)
root.mainloop()

This script creates the window in Figure 8-16 when launched (its button’s background is a sort of green, but you’ll have to trust me on this). Pressing the button pops up the color selection dialog shown earlier; the color you pick in that dialog becomes the background color of this button after you press OK.

Figure 8-16. setcolor main window

Color strings are also printed to the stdout stream (the console window); run this on your computer to experiment with available color settings:

C:...PP4EGuiTour> python setcolor.py
#0080c0
#408080
#77d5df

We’ve seen most of the standard dialogs and we’ll use these pop ups in examples throughout the rest of this book. But for more details on other calls and options available, either consult other tkinter documentation or browse the source code of the modules used at the top of the dialogTable module in Example 8-8; all are simple Python files installed in the tkinter subdirectory of the Python source library on your machine (e.g., in C:Python31Lib on Windows). And keep this demo bar example filed away for future reference; we’ll reuse it later in the tour for callback actions when we meet other button-like widgets.

Now, when the script is run with a command-line argument (e.g., python dlg-custom.py 1), it makes its pop ups modal instead. Because modal dialogs grab all of the interface’s attention, the main window becomes inactive in this mode until the pop up is killed; you can’t even click on it to reactivate it while the dialog is open. Because of that, you can never make more than one copy of the pop up on-screen at once, as shown in Figure 8-19.

Figure 8-19. A modal custom dialog at work

In fact, the call to the dialog function in this script doesn’t return until the dialog window on the left is dismissed by pressing its OK button. The net effect is that modal dialogs impose a function call–like model on an otherwise event-driven programming model; user inputs can be processed right away, not in a callback handler triggered at some arbitrary point in the future.

Forcing such a linear control flow on a GUI takes a bit of extra work, though. The secret to locking other windows and waiting for a reply boils down to three lines of code, which are a general pattern repeated in most custom modal dialogs.

Because the script waits for a window destroy event, it must also arrange for a callback handler to destroy the window in response to interaction with widgets in the dialog window (the only window active). This example’s dialog is simply informational, so its OK button calls the window’s destroy method. In user-input dialogs, we might instead install an Enter key-press callback handler that fetches data typed into an Entry widget and then calls destroy (see later in this chapter).

Modal dialogs are typically implemented by waiting for a newly created pop-up window’s destroy event, as in this example. But other schemes are viable too. For example, it’s possible to create dialog windows ahead of time, and show and hide them as needed with the top-level window’s deiconify and withdraw methods (see the alarm scripts near the end of Chapter 9 for details). Given that window creation speed is generally fast enough as to appear instantaneous today, this is much less common than making and destroying a window from scratch on each interaction.

It’s also possible to implement a modal state by waiting for a tkinter variable to change its value, instead of waiting for a window to be destroyed. See this chapter’s later discussion of tkinter variables (which are class objects, not normal Python variables) and the wait_variable method discussed near the end of Chapter 9 for more details. This scheme allows a long-lived dialog box’s callback handler to signal a state change to a waiting main program, without having to destroy the dialog box.

Finally, if you call the mainloop method recursively, the call won’t return until the widget quit method has been invoked. The quit method terminates a mainloop call, and so normally ends a GUI program. But it will simply exit a recursive mainloop level if one is active. Because of this, modal dialogs can also be written without wait method calls if you are careful. For instance, Example 8-14 works the same way as the modal mode of dlg-custom.

from tkinter import *

def dialog():
    win = Toplevel()                                      # make a new window
    Label(win,  text='Hard drive reformatted!').pack()    # add a few widgets
    Button(win, text='OK', command=win.quit).pack()       # set quit callback
    win.protocol('WM_DELETE_WINDOW', win.quit)            # quit on wm close too!

    win.focus_set()          # take over input focus,
    win.grab_set()           # disable other windows while I'm open,
    win.mainloop()           # and start a nested event loop to wait
    win.destroy()
    print('dialog exit')

root = Tk()
Button(root, text='popup', command=dialog).pack()
root.mainloop()

If you go this route, be sure to call quit rather than destroy in dialog callback handlers (destroy doesn’t terminate the mainloop level), and be sure to use protocol to make the window border close button call quit too (or else it won’t end the recursive mainloop level call and may generate odd error messages when your program finally exits). Because of this extra complexity, you’re probably better off using wait_window or wait_variable, not recursive mainloop calls.

We’ll see how to build form-like dialogs with labels and input fields later in this chapter when we meet Entry, and again when we study the grid manager in Chapter 9. For more custom dialog examples, see ShellGui (Chapter 10), PyMailGUI (Chapter 14), PyCalc (Chapter 19), and the nonmodal form.py (Chapter 12). Here, we’re moving on to learn more about events that will prove to be useful currency at later tour destinations.

Before we move on, one event merits a few extra words: the <Destroy> event (whose name is case significant) is run when a widget is being destroyed, as a result of both script method calls and window closures in general, including those at program exit. If you bind this on a window, it will be triggered once for each widget in the window; the callback’s event argument widget attribute gives the widget being destroyed, and you can check this to detect a particular widget’s destruction. If you bind this on a specific widget instead, it will be triggered once for that widget’s destruction only.

It’s important to know that a widget is in a “half dead” state (Tk’s terminology) when this event is triggered—it still exists, but most operations on it fail. Because of that, the <Destroy> event is not intended for GUI activity in general; for instance, checking a text widget’s changed state or fetching its content in a <Destroy> handler can both fail with exceptions. In addition, this event’s handler cannot cancel the destruction in general and resume the GUI; if you wish to intercept and verify or suppress window closes when a user clicks on a window’s X button, use WM_DELETE_WINDOW in top-level windows’ protocol methods as described earlier in this chapter.

You should also know that running a tkinter widget’s quit method does not trigger any <Destroy> events on exit, and even leads to a fatal Python error on program exit in 3.X if any <Destroy> event handlers are registered. Because of this, programs that bind this event for non-GUI window exit actions should usually call destroy instead of quit to close, and rely on the fact that a program exits when the last remaining or only Tk root window (default or explicit) is destroyed as described earlier. This precludes using quit for immediate shutdowns, though you can still run sys.exit for brute-force exits.

A script can also perform program exit actions in code run after the mainloop call returns, but the GUI is gone completely at this point, and this code is not associated with any particular widget. Watch for more on this event when we study the PyEdit example program in Chapter 11; at the risk of spoiling the end of this story, we’ll find it unusable for verifying changed text saves.

Generally speaking, the values typed into and displayed by Entry widgets are set and fetched with either tied “variable” objects (described later in this chapter) or Entry widget method calls such as this one:

ent.insert(0, 'some text')          # set value
value = ent.get()                   # fetch value (a string)

The first parameter to the insert method gives the position where the text is to be inserted. Here, “0” means the front because offsets start at zero, and integer 0 and string '0' mean the same thing (tkinter method arguments are always converted to strings if needed). If the Entry widget might already contain text, you also generally need to delete its contents before setting it to a new value, or else new text will simply be added to the text already present:

ent.delete(0, END)                  # first, delete from start to end
ent.insert(0, 'some text')          # then set value

The name END here is a preassigned tkinter constant denoting the end of the widget; we’ll revisit it in Chapter 9 when we meet the full-blown and multiple-line Text widget (Entry’s more powerful cousin). Since the widget is empty after the deletion, this statement sequence is equivalent to the prior one:

ent.delete('0', END)                # delete from start to end
ent.insert(END, 'some text')        # add at end of empty text

Either way, if you don’t delete the text first, new text that is inserted is simply added. If you want to see how, try changing the fetch function in Example 8-17 to look like this—an “x” is added at the beginning and end of the input field on each button or key press:

def fetch():
    print('Input => "%s"' % ent.get())        # get text
    ent.insert(END, 'x')                      # to clear: ent.delete('0', END)
    ent.insert(0, 'x')                        # new text simply added

In later examples, we’ll also see the Entry widget’s state='disabled' option, which makes it read only, as well as its show='*' option, which makes it display each character as a * (useful for password-type inputs). Try this out on your own by changing and running this script for a quick look. Entry supports other options we’ll skip here, too; see later examples and other resources for additional details.

Later on this tour, we’ll see how to make similar form layouts with the grid geometry manager, where we arrange by row and column numbers instead of frames. But now that we have a handle on form layout, let’s see how to apply the modal dialog techniques we met earlier to a more complex input display.

Example 8-19 uses the prior example’s makeform and fetch functions to generate a form and prints its contents, much as before. Here, though, the input fields are attached to a new Toplevel pop-up window created on demand, and an OK button is added to the new window to trigger a window destroy event that erases the pop up. As we learned earlier, the wait_window call pauses until the destroy happens.

# make form dialog modal; must fetch before destroy with entries

from tkinter import *
from entry2 import makeform, fetch, fields

def show(entries, popup):
    fetch(entries)                  # must fetch before window destroyed!
    popup.destroy()                 # fails with msgs if stmt order is reversed

def ask():
    popup = Toplevel()              # show form in modal dialog window
    ents = makeform(popup, fields)
    Button(popup, text='OK', command=(lambda: show(ents, popup))).pack()
    popup.grab_set()
    popup.focus_set()
    popup.wait_window()             # wait for destroy here

root = Tk()
Button(root, text='Dialog', command=ask).pack()
root.mainloop()

When you run this code, pressing the button in this program’s main window creates the blocking form input dialog in Figure 8-25, as expected.

Figure 8-25. entry2-modal (and entry3-modal) displays

But a subtle danger is lurking in this modal dialog code: because it fetches user inputs from Entry widgets embedded in the popped-up display, it must fetch those inputs before destroying the pop-up window in the OK press callback handler. It turns out that a destroy call really does destroy all the child widgets of the window destroyed; trying to fetch values from a destroyed Entry not only doesn’t work, but also generates a traceback with error messages in the console window. Try reversing the statement order in the show function to see for yourself.

To avoid this problem, we can either be careful to fetch before destroying, or use tkinter variables, the subject of the next section.

When I first studied check buttons, my initial reaction was: why do we need tkinter variables here at all when we can register button-press callbacks? Linked variables may seem superfluous at first glance, but they simplify some GUI chores. Instead of asking you to accept this blindly, though, let me explain why.

Keep in mind that a Checkbutton’s command callback will be run on every press, whether the press toggles the check button to a selected or a deselected state. Because of that, if you want to run an action immediately when a check button is pressed, you will generally want to check the button’s current value in the callback handler. Because there is no check button “get” method for fetching values, you usually need to interrogate an associated variable to see if the button is on or off.

Moreover, some GUIs simply let users set check buttons without running command callbacks at all and fetch button settings at some later point in the program. In such a scenario, variables serve to automatically keep track of button settings. The demoCheck script’s report method represents this latter approach.

Of course, you could manually keep track of each button’s state in press callback handlers, too. Example 8-23 keeps its own list of state toggles and updates it manually on command press callbacks.

# check buttons, the hard way (without variables)

from tkinter import *
states = []                            # change object not name
def onPress(i):                        # keep track of states
    states[i] = not states[i]          # changes False->True, True->False

root = Tk()
for i in range(10):
    chk = Checkbutton(root, text=str(i), command=(lambda i=i: onPress(i)) )
    chk.pack(side=LEFT)
    states.append(False)
root.mainloop()
print(states)                          # show all states on exit

The lambda here passes along the pressed button’s index in the states list. Otherwise, we would need a separate callback function for each button. Here again, we need to use a default argument to pass the loop variable into the lambda, or the loop variable will be its value on the last loop iteration for all 10 of the generated functions (each press would update the tenth item in the list; see Chapter 7 for background details on this). When run, this script makes the 10–check button display in Figure 8-27.

Figure 8-27. Manual check button state window

Manually maintained state toggles are updated on every button press and are printed when the GUI exits (technically, when the mainloop call returns); it’s a list of Boolean state values, which could also be integers 1 or 0 if we cared to exactly imitate the original:

C:...PP4EGuiTour> python demo-check-manual.py
[False, False, True, False, True, False, False, False, True, False]

This works, and it isn’t too horribly difficult to manage manually. But linked tkinter variables make this task noticeably easier, especially if you don’t need to process check button states until some time in the future. This is illustrated in Example 8-24.

# check buttons, the easy way

from tkinter import *
root = Tk()
states = []
for i in range(10):
    var = IntVar()
    chk = Checkbutton(root, text=str(i), variable=var)
    chk.pack(side=LEFT)
    states.append(var)
root.mainloop()                               # let tkinter keep track
print([var.get() for var in states])          # show all states on exit (or map/lambda)

This looks and works the same way, but there is no command button-press callback handler at all, because toggle state is tracked by tkinter automatically:

C:...PP4EGuiTour> python demo-check-auto.py
[0, 0, 1, 1, 0, 0, 1, 0, 0, 1]

The point here is that you don’t necessarily have to link variables with check buttons, but your GUI life will be simpler if you do. The list comprehension at the very end of this script, by the way, is equivalent to the following unbound method and lambda/bound-method map call forms:

print(list(map(IntVar.get, states)))
print(list(map(lambda var: var.get(), states)))

Though comprehensions are common in Python today, the form that seems clearest to you may very well depend upon your shoe size…

So, why variables here? For one thing, radio buttons also have no “get” widget method to fetch the selection in the future. More importantly, in radio button groups, the value and variable settings turn out to be the whole basis of single-choice behavior. In fact, to make radio buttons work normally at all, it’s crucial that they are all associated with the same tkinter variable and have distinct value settings. To truly understand why, though, you need to know a bit more about how radio buttons and variables do their stuff.

We’ve already seen that changing a widget changes its associated tkinter variable, and vice versa. But it’s also true that changing a variable in any way automatically changes every widget it is associated with. In the world of radio buttons, pressing a button sets a shared variable, which in turn impacts other buttons associated with that variable. Assuming that all radio buttons have distinct values, this works as you expect it to work. When a button press changes the shared variable to the pressed button’s value, all other buttons are deselected, simply because the variable has been changed to a value not their own.

This is true both when the user selects a button and changes the shared variable’s value implicitly, but also when the variable’s value is set manually by a script. For instance, when Example 8-25 sets the shared variable to the last of the demo’s names initially (with self.var.set), it selects that demo’s button and deselects all the others in the process; this way, only one is selected at first. If the variable was instead set to a string that is not any demo’s name (e.g., ' '), all buttons would be deselected at startup.

This ripple effect is a bit subtle, but it might help to know that within a group of radio buttons sharing the same variable, if you assign a set of buttons the same value, the entire set will be selected if any one of them is pressed. Consider Example 8-26, which creates Figure 8-29, for instance. All buttons start out deselected this time (by initializing the shared variable to none of their values), but because radio buttons 0, 3, 6, and 9 have value 0 (the remainder of division by 3), all are selected if any are selected.

Figure 8-29. Radio buttons gone bad?

# see what happens when some buttons have same value

from tkinter import *
root = Tk()
var = StringVar()
for i in range(10):
    rad = Radiobutton(root, text=str(i), variable=var, value=str(i % 3))
    rad.pack(side=LEFT)
var.set(' ') # deselect all initially
root.mainloop()

If you press 1, 4, or 7 now, all three of these are selected, and any existing selections are cleared (they don’t have the value “1”). That’s not normally what you want—radio buttons are usually a single-choice group (check buttons handle multiple-choice inputs). If you want them to work as expected, be sure to give each radio button the same variable but a unique value across the entire group. In the demoRadio script, for instance, the name of the demo provides a naturally unique value for each button.

Strictly speaking, we could get by without tkinter variables here, too. Example 8-27, for instance, implements a single-selection model without variables, by manually selecting and deselecting widgets in the group, in a callback handler of its own. On each press event, it issues deselect calls for every widget object in the group and select for the one pressed.

"""
radio buttons, the hard way (without variables)
note that deselect for radio buttons simply sets the button's
associated value to a null string, so we either need to still
give buttons unique values, or use checkbuttons here instead;
"""

from tkinter import *
state = ''
buttons = []

def onPress(i):
    global state
    state = i
    for btn in buttons:
        btn.deselect()
    buttons[i].select()

root = Tk()
for i in range(10):
    rad = Radiobutton(root, text=str(i),
                            value=str(i), command=(lambda i=i: onPress(i)) )
    rad.pack(side=LEFT)
    buttons.append(rad)

onPress(0)                   # select first initially
root.mainloop()
print(state)                 # show state on exit

This works. It creates a 10-radio button window that looks just like the one in Figure 8-29 but implements a single-choice radio-style interface, with current state available in a global Python variable printed on script exit. By associating tkinter variables and unique values, though, you can let tkinter do all this work for you, as shown in Example 8-28.

# radio buttons, the easy way

from tkinter import *
root = Tk()                     # IntVars work too
var  = IntVar(0)                # select 0 to start
for i in range(10):
    rad = Radiobutton(root, text=str(i), value=i, variable=var)
    rad.pack(side=LEFT)
root.mainloop()
print(var.get())                # show state on exit

This works the same way, but it is a lot less to type and debug. Notice that this script associates the buttons with an IntVar, the integer type sibling of StringVar, and initializes it to zero (which is also its default); as long as button values are unique, integers work fine for radio buttons too.

One minor word of caution: you should generally hold onto the tkinter variable object used to link radio buttons for as long as the radio buttons are displayed. Assign it to a module global variable, store it in a long-lived data structure, or save it as an attribute of a long-lived class instance object as done by demoRadio. Just make sure you retain a reference to it somehow. You normally will in order to fetch its state anyhow, so it’s unlikely that you’ll ever care about what I’m about to tell you.

But in the current tkinter, variable classes have a __del__ destructor that automatically unsets a generated Tk variable when the Python object is reclaimed (i.e., garbage collected). The upshot is that all of your radio buttons may be deselected if the variable object is collected, at least until the next press resets the Tk variable to a new value. Example 8-29 shows one way to trigger this.

# hold on to your radio variables (an obscure thing, indeed)

from tkinter import *
root = Tk()

def radio1():                   # local vars are temporary
    #global tmp                 # making it global fixes the problem
    tmp = IntVar()
    for i in range(10):
        rad = Radiobutton(root, text=str(i), value=i, variable=tmp)
        rad.pack(side=LEFT)
    tmp.set(5)  # select 6th button

radio1()
root.mainloop()

This should come up with button “5” selected initially, but it doesn’t. The variable referenced by local tmp is reclaimed on function exit, the Tk variable is unset, and the 5 setting is lost (all buttons come up unselected). These radio buttons work fine, though, once you start pressing them, because that resets the internal Tk variable. Uncommenting the global statement here makes 5 start out set, as expected.

This phenomenon seems to have grown even worse in Python 3.X: not only is “5” not selected initially, but moving the mouse cursor over the unselected buttons seems to select many at random until one is pressed. (In 3.X we also need to initialize a StringVar shared by radio buttons as we did in this section’s earlier examples, or else its empty string default selects all of them!)

Of course, this is an atypical example—as coded, there is no way to know which button is pressed, because the variable isn’t saved (and command isn’t set). It makes little sense to use a group of radio buttons at all if you cannot query its value later. In fact, this is so obscure that I’ll just refer you to demo-radio-clear2.py in the book’s examples distribution for an example that works hard to trigger this oddity in other ways. You probably won’t care, but you can’t say that I didn’t warn you if you ever do.

As you can probably tell, scales offer a variety of ways to process their selections: immediately in move callbacks, or later by fetching current positions with variables or scale method calls. In fact, tkinter variables aren’t needed to program scales at all—simply register movement callbacks or call the scale get method to fetch scale values on demand, as in the simpler scale example in Example 8-31.

from tkinter import *
root = Tk()
scl = Scale(root, from_=-100, to=100, tickinterval=50, resolution=10)
scl.pack(expand=YES, fill=Y)

def report():
    print(scl.get())

Button(root, text='state', command=report).pack(side=RIGHT)
root.mainloop()

Figure 8-31 shows two instances of this program running on Windows—one stretched and one not (the scales are packed to grow vertically on resizes). Its scale displays a range from −100 to 100, uses the resolution option to adjust the current position up or down by 10 on every move, and sets the tickinterval option to show values next to the scale in increments of 50. When you press the State button in this script’s window, it calls the scale’s get method to display the current setting, without variables or callbacks of any kind:

C:...PP4EGuiTour> python demo-scale-simple.py
0
60
-70

Figure 8-31. A simple scale without variables

Frankly, the only reason tkinter variables are used in the demoScale script at all is to synchronize scales. To make the demo interesting, this script associates the same tkinter variable object with both scales. As we learned in the last section, changing a widget changes its variable, but changing a variable also changes all the widgets it is associated with. In the world of sliders, moving the slide updates that variable, which in turn might update other widgets associated with the same variable. Because this script links one variable with two scales, it keeps them automatically in sync: moving one scale moves the other, too, because the shared variable is changed in the process and so updates the other scale as a side effect.

Linking scales like this may or may not be typical of your applications (and borders on deep magic), but it’s a powerful tool once you get your mind around it. By linking multiple widgets on a display with tkinter variables, you can keep them automatically in sync, without making manual adjustments in callback handlers. On the other hand, the synchronization could be implemented without a shared variable at all by calling one scale’s set method from a move callback handler of the other. I’ll leave such a manual mutation as a suggested exercise, though. One person’s deep magic might be another’s useful hack.

The only substantially tricky part of this script is its use of Python’s built-in __import__ function to import a module by a name string. Look at the following two lines from the script’s addComponents function:

module = __import__(demo)             # import module by name string
part = module.Demo(root)              # attach an instance of its Demo

This is equivalent to saying something like this:

import 'demoDlg'
part = 'demoDlg'.Demo(root)

However, the preceding code is not legal Python syntax—the module name in import statements and dot expressions must be a Python variable, not a string; moreover, in an import the name is taken literally (not evaluated), and in dot syntax must evaluate to the object (not its string name). To be generic, addComponents steps through a list of name strings and relies on __import__ to import and return the module identified by each string. In fact, the for loop containing these statements works as though all of these statements were run:

import demoDlg, demoRadio, demoCheck, demoScale
part = demoDlg.Demo(root)
part = demoRadio.Demo(root)
part = demoCheck.Demo(root)
part = demoScale.Demo(root)

But because the script uses a list of name strings, it’s easier to change the set of demos embedded—simply change the list, not the lines of executable code. Further, such data-driven code tends to be more compact, less redundant, and easier to debug and maintain. Incidentally, modules can also be imported from name strings by dynamically constructing and running import statements, like this:

for demo in demoModules:
    exec('from %s import Demo' % demo)       # make and run a from
    part = eval('Demo')(root)                # fetch known import name by string

The exec statement compiles and runs a Python statement string (here, a from to load a module’s Demo class); it works here as if the statement string were pasted into the source code where the exec statement appears. The following achieves the same effect by running an import statement instead:

for demo in demoModules:
    exec('import %s' % demo)                 # make and run an import
    part = eval(demo).Demo(root)             # fetch module variable by name too

Because it supports any sort of Python statement, these exec/eval techniques are more general than the __import__ call, but can also be slower, since they must parse code strings before running them.^[33] However, that slowness may not matter in a GUI; users tend to be significantly slower than parsers.

One other alternative worth mentioning: notice how Example 8-32 configures and repacks each attached demo frame for its role in this GUI:

def addComponents(root):
    for demo in demoModules:
        module = __import__(demo)                       # import by name string
        part = module.Demo(root)                        # attach an instance
        part.config(bd=2, relief=GROOVE)                # or pass configs to Demo()
        part.pack(side=LEFT, expand=YES, fill=BOTH)     # grow, stretch with window

Because the demo classes use their **options arguments to support constructor arguments, though, we could configure at creation time, too. For example, if we change this code as follows, it produces the slightly different composite window captured in Figure 8-33 (stretched a bit horizontally for illustration, too; you can run this as demoAll-frm-ridge.py in the examples package):

def addComponents(root):
    for demo in demoModules:
        module = __import__(demo)                       # import by name string
        part = module.Demo(root, bd=6, relief=RIDGE)    # attach, config instance
        part.pack(side=LEFT, expand=YES, fill=BOTH)     # grow, stretch with window

Because the demo classes both subclass Frame and support the usual construction argument protocols, they become true widgets—specialized tkinter frames that implement an attachable package of widgets and support flexible configuration techniques.

Figure 8-33. demoAll_frm: configure when constructed

As we saw in Chapter 7, attaching nested frames like this is really just one way to reuse GUI code structured as classes. It’s just as easy to customize such interfaces by subclassing rather than embedding. Here, though, we’re more interested in deploying an existing widget package than changing it, so attachment is the pattern we want. The next two sections show two other ways to present such precoded widget packages to users—in pop-up windows and as autonomous programs.

If you backtrack to Chapter 5 to study the portable launcher module used by Example 8-34 to start programs, you’ll see that it works by using os.spawnv on Windows and os.fork/exec on others. The net effect is that the GUI processes are effectively started by launching command lines. These techniques work well, but as we learned in Chapter 5, they are members of a larger set of program launching tools that also includes os.popen, os.system, os.startfile, and the subprocess and multiprocessing modules; these tools can vary subtly in how they handle shell window connections, parent process exits, and more.

For example, the multiprocessing module we studied in Chapter 5 provides a similarly portable way to run our GUIs as independent processes, as demonstrated in Example 8-35. When run, it produces the exact same windows shown in Figure 8-35, except that the label in the main window is different.

"""
4 demo classes run as independent program processes: multiprocessing;
multiprocessing allows us to launch named functions with arguments,
but not lambdas, because they are not pickleable on Windows (Chapter 5);
multiprocessing also has its own IPC tools like pipes for communication;
"""

from tkinter import *
from multiprocessing import Process
demoModules = ['demoDlg', 'demoRadio', 'demoCheck', 'demoScale']

def runDemo(modname):                     # run in a new process
    module = __import__(modname)          # build gui from scratch
    module.Demo().mainloop()

if __name__ == '__main__':
    for modname in demoModules:                               # in __main__ only!
        Process(target=runDemo, args=(modname,)).start()

    root = Tk()                                               # parent process GUI
    root.title('Processes')
    Label(root, text='Multiple program demo: multiprocessing', bg='white').pack()
    root.mainloop()

Operationally, this version differs on Windows only in that:

Also observe how we start a simple named function in the new Process. As we learned in Chapter 5, the target must be pickleable on Windows (which essentially means importable), so we cannot use lambdas to pass extra data in the way we typically could in tkinter callbacks. The following coding alternatives both fail with errors on Windows:

Process(target=(lambda: runDemo(modname))).start()            # these both fail!

Process(target=(lambda: __import__(modname).Demo().mainloop())).start()

We won’t recode our GUI program launcher script with any of the other techniques available, but feel free to experiment on your own using Chapter 5 as a resource. Although not universally applicable, the whole point of tools like the PortableLauncher class is to hide such details so we can largely forget them.

Spawning GUIs as programs is the ultimate in code independence, but it makes the lines of communication between components more complex. For instance, because the demos run as programs here, there is no easy way to run all their report methods from the launching script’s window pictured in the upper right of Figure 8-35. In fact, the States button is gone this time, and we only get PortableLauncher messages in stdout as the demos start up in Example 8-34:

C:...PP4EGuiTour> python demoAll_prg.py
demoDlg
demoRadio
demoCheck
demoScale

On some platforms, messages printed by the demo programs (including their own State buttons) may show up in the original console window where this script is launched; on Windows, the os.spawnv call used to start programs by launchmodes in Example 8-34 completely disconnects the child program’s stdout stream from its parent, but the multiprocessing scheme of Example 8-35 does not. Regardless, there is no direct way to call all demos’ report methods at once—they are spawned programs in distinct address spaces, not imported modules.

Of course, we could trigger report methods in the spawned programs with some of the Inter-Process Communication (IPC) mechanisms we met in Chapter 5. For instance:

Given their event-driven nature, GUI-based programs like our demos also need to avoid becoming stuck in wait states—they cannot be blocked while waiting for requests on IPC devices like those above, or they won’t be responsive to users (and might not even redraw themselves). Because of that, they may also have be augmented with threads, timer-event callbacks, nonblocking input calls, or some combination of such techniques to periodically check for incoming messages on pipes, fifos, or sockets. As we’ll see, the tkinter after method call described near the end of the next chapter is ideal for this: it allows us to register a callback to run periodically to check for incoming requests on such IPC tools.

We’ll explore some of these options near the end of Chapter 10, after we’ve looked at GUI threading topics. But since this is well beyond the scope of the current chapter’s simple demo programs, I’ll leave such cross-program extensions up to more parallel-minded readers for now.

A postscript: I coded the demo launcher bars deployed by the last four examples to demonstrate all the different ways that their widgets can be used. They were not developed with general-purpose reusability in mind; in fact, they’re not really useful outside the context of introducing widgets in this book.

That was by design; most tkinter widgets are easy to use once you learn their interfaces, and tkinter already provides lots of configuration flexibility by itself. But if I had it in mind to code checkbutton and radiobutton classes to be reused as general library components, they would have to be structured differently:

Example 8-36 shows one way to code check button and radio button bars as library components. It encapsulates the notion of associating tkinter variables and imposes a common usage mode on callers—state fetches rather than press callbacks—to keep the interface simple.

"""
check and radio button bar classes for apps that fetch state later;
pass a list of options, call state(), variable details automated
"""

from tkinter import *

class Checkbar(Frame):
    def __init__(self, parent=None, picks=[], side=LEFT, anchor=W):
        Frame.__init__(self, parent)
        self.vars = []
        for pick in picks:
            var = IntVar()
            chk = Checkbutton(self, text=pick, variable=var)
            chk.pack(side=side, anchor=anchor, expand=YES)
            self.vars.append(var)
    def state(self):
        return [var.get() for var in self.vars]

class Radiobar(Frame):
    def __init__(self, parent=None, picks=[], side=LEFT, anchor=W):
        Frame.__init__(self, parent)
        self.var = StringVar()
        self.var.set(picks[0])
        for pick in picks:
            rad = Radiobutton(self, text=pick, value=pick, variable=self.var)
            rad.pack(side=side, anchor=anchor, expand=YES)
    def state(self):
        return self.var.get()

if __name__ == '__main__':
    root = Tk()
    lng = Checkbar(root, ['Python', 'C#', 'Java', 'C++'])
    gui = Radiobar(root, ['win', 'x11', 'mac'], side=TOP, anchor=NW)
    tgl = Checkbar(root, ['All'])

    gui.pack(side=LEFT, fill=Y)
    lng.pack(side=TOP,  fill=X)
    tgl.pack(side=LEFT)
    lng.config(relief=GROOVE, bd=2)
    gui.config(relief=RIDGE,  bd=2)

    def allstates():
        print(gui.state(), lng.state(), tgl.state())

    from quitter import Quitter
    Quitter(root).pack(side=RIGHT)
    Button(root, text='Peek', command=allstates).pack(side=RIGHT)
    root.mainloop()

To reuse these classes in your scripts, import and call them with a list of the options that you want to appear in a bar of check buttons or radio buttons. This module’s self-test code at the bottom of the file gives further usage details. It generates Figure 8-36—a top-level window that embeds two Checkbars, one Radiobar, a Quitter button to exit, and a Peek button to show bar states—when this file is run as a program instead of being imported.

Figure 8-36. buttonbars self-test window

Here’s the stdout text you get after pressing Peek—the results of these classes’ state methods:

x11 [1, 0, 1, 1] [0]
win [1, 0, 0, 1] [1]

The two classes in this module demonstrate how easy it is to wrap tkinter interfaces to make them easier to use; they completely abstract away many of the tricky parts of radio button and check button bars. For instance, you can forget about linked variable details completely if you use such higher-level classes instead—simply make objects with option lists and call their state methods later. If you follow this path to its logical conclusion, you might just wind up with a higher-level widget library on the order of the Pmw package mentioned in Chapter 7.

On the other hand, these classes are still not universally applicable; if you need to run actions when these buttons are pressed, for instance, you’ll need to use other high-level interfaces. Luckily, Python/tkinter already provides plenty. Later in this book, we’ll again use the widget combination and reuse techniques introduced in this section to construct larger GUIs like text editors, email clients and calculators. For now, this first chapter in the widget tour is about to make one last stop—the photo shop.

While we’re at it, it’s not much extra work to allow viewing all images in a directory, using some of the directory path tools we met in the first part of this book. Example 8-44, for instance, simply opens a new Toplevel pop-up window for each image in a directory (given as a command-line argument or a default), taking care to skip nonimage files by catching exceptions—error messages are both printed and displayed in the bad file’s pop-up window.

"""
display all images in a directory in pop-up windows
GIFs work in basic tkinter, but JPEGs will be skipped without PIL
"""

import os, sys
from tkinter import *
from PIL.ImageTk import PhotoImage          # <== required for JPEGs and others

imgdir = 'images'
if len(sys.argv) > 1: imgdir = sys.argv[1]
imgfiles = os.listdir(imgdir)               # does not include directory prefix

main = Tk()
main.title('Viewer')
quit = Button(main, text='Quit all', command=main.quit, font=('courier', 25))
quit.pack()
savephotos = []

for imgfile in imgfiles:
    imgpath = os.path.join(imgdir, imgfile)
    win = Toplevel()
    win.title(imgfile)
    try:
        imgobj = PhotoImage(file=imgpath)
        Label(win, image=imgobj).pack()
        print(imgpath, imgobj.width(), imgobj.height())      # size in pixels
        savephotos.append(imgobj)                            # keep a reference
    except:
        errmsg = 'skipping %s
%s' % (imgfile, sys.exc_info()[1])
        Label(win, text=errmsg).pack()

main.mainloop()

Run this code on your own to see the windows it generates. If you do, you’ll get one main window with a Quit button to kill all the windows at once, plus as many pop-up image view windows as there are images in the directory. This is convenient for a quick look, but not exactly the epitome of user friendliness for large directories! The sample images directory used for testing, for instance, has 59 images, yielding 60 pop-up windows; those created by your digital camera may have many more. To do better, let’s move on to the next section.

As is, the viewer saves the generated thumbnail image in a file, so it can be loaded quickly the next time the script is run. This isn’t strictly required—Example 8-46, for instance, customizes the thumbnail generation function to generate the thumbnail images in memory, but never save them.

There is no noticeable speed difference for very small image collections. If you run these alternatives on larger image collections, though, you’ll notice that the original version in Example 8-45 gains a big performance advantage by saving and loading the thumbnails to files. On one test with many large image files on my machine (some 320 images from a digital camera memory stick and an admittedly underpowered laptop), the original version opens the GUI in roughly just 5 seconds after its initial run to cache thumbnails, compared to as much as 1 minute and 20 seconds for Example 8-46: a factor of 16 slower. For thumbnails, loading from files is much quicker than recalculation.

"""
same, but make thumb images in memory without saving to or loading from files:
seems just as fast for small directories, but saving to files makes startup much
quicker for large image collections; saving may be needed in some apps (web pages)
"""

import os, sys
from PIL import Image
from tkinter import Tk
import viewer_thumbs

def makeThumbs(imgdir, size=(100, 100), subdir='thumbs'):
    """
    create thumbs in memory but don't cache to files
    """
    thumbs = []
    for imgfile in os.listdir(imgdir):
        imgpath = os.path.join(imgdir, imgfile)
        try:
            imgobj = Image.open(imgpath)          # make new thumb
            imgobj.thumbnail(size)
            thumbs.append((imgfile, imgobj))
        except:
            print("Skipping: ", imgpath)
    return thumbs

if __name__ == '__main__':
    imgdir = (len(sys.argv) > 1 and sys.argv[1]) or 'images'
    viewer_thumbs.makeThumbs = makeThumbs
    main, save = viewer_thumbs.viewer(imgdir, kind=Tk)
    main.mainloop()

The next variations on our viewer are purely cosmetic, but they illustrate tkinter layout concepts. If you look at Figure 8-45 long enough, you’ll notice that its layout of thumbnails is not as uniform as it could be. Individual rows are fairly coherent because the GUI is laid out by row frames, but columns can be misaligned badly due to differences in image shape. Different packing options don’t seem to help (and can make matters even more askew—try it), and arranging by column frames would just shift the problem to another dimension. For larger collections, it could become difficult to locate and open specific images.

With just a little extra work, we can achieve a more uniform layout by either laying out the thumbnails in a grid, or using uniform fixed-size buttons. Example 8-47 positions buttons in a row/column grid by using the tkinter grid geometry manager—a topic we will explore in more detail in the next chapter, so like the canvas, you should consider some of this code to be a preview and segue, too. In short, grid arranges its contents by row and column; we’ll learn all about the stickiness of the Quit button here in Chapter 9.

"""
same as viewer_thumbs, but uses the grid geometry manager to try to achieve
a more uniform layout; can generally achieve the same with frames and pack
if buttons are all fixed and uniform in size;
"""

import sys, math
from tkinter import *
from PIL.ImageTk import PhotoImage
from viewer_thumbs import makeThumbs, ViewOne

def viewer(imgdir, kind=Toplevel, cols=None):
    """
    custom version that uses gridding
    """
    win = kind()
    win.title('Viewer: ' + imgdir)
    thumbs = makeThumbs(imgdir)
    if not cols:
        cols = int(math.ceil(math.sqrt(len(thumbs))))     # fixed or N x N

    rownum = 0
    savephotos = []
    while thumbs:
        thumbsrow, thumbs = thumbs[:cols], thumbs[cols:]
        colnum = 0
        for (imgfile, imgobj) in thumbsrow:
            photo   = PhotoImage(imgobj)
            link    = Button(win, image=photo)
            handler = lambda savefile=imgfile: ViewOne(imgdir, savefile)
            link.config(command=handler)
            link.grid(row=rownum, column=colnum)
            savephotos.append(photo)
            colnum += 1
        rownum += 1

    Button(win, text='Quit', command=win.quit).grid(columnspan=cols, stick=EW)
    return win, savephotos

if __name__ == '__main__':
    imgdir = (len(sys.argv) > 1 and sys.argv[1]) or 'images'
    main, save = viewer(imgdir, kind=Tk)
    main.mainloop()

Figure 8-47 displays the effect of gridding—our buttons line up in rows and columns in a more uniform fashion than in Figure 8-45, because they are positioned by both row and column, not just by rows. As we’ll see in the next chapter, gridding can help any time our displays are two-dimensional by nature.

Figure 8-47. Gridded thumbnail selection GUI

Gridding helps—rows and columns align regularly now—but image shape still makes this less than ideal. We can achieve a layout that is perhaps even more uniform than gridding by giving each thumbnail button a fixed size. Buttons are sized to their images (or text) by default, but we can always override this if needed. Example 8-48 does the trick. It sets the height and width of each button to match the maximum dimension of the thumbnail icon, so it is neither too thin nor too high. Assuming all thumbnails have the same maximum dimension (something our thumb-maker ensures), this will achieve the desired layout.

"""
use fixed size for thumbnails, so align regularly; size taken from image
object, assume all same max; this is essentially what file selection GUIs do;
"""

import sys, math
from tkinter import *
from PIL.ImageTk import PhotoImage
from viewer_thumbs import makeThumbs, ViewOne

def viewer(imgdir, kind=Toplevel, cols=None):
    """
    custom version that lays out with fixed-size buttons
    """
    win = kind()
    win.title('Viewer: ' + imgdir)
    thumbs = makeThumbs(imgdir)
    if not cols:
        cols = int(math.ceil(math.sqrt(len(thumbs))))      # fixed or N x N

    savephotos = []
    while thumbs:
        thumbsrow, thumbs = thumbs[:cols], thumbs[cols:]
        row = Frame(win)
        row.pack(fill=BOTH)
        for (imgfile, imgobj) in thumbsrow:
            size    = max(imgobj.size)                     # width, height
            photo   = PhotoImage(imgobj)
            link    = Button(row, image=photo)
            handler = lambda savefile=imgfile: ViewOne(imgdir, savefile)
            link.config(command=handler, width=size, height=size)
            link.pack(side=LEFT, expand=YES)
            savephotos.append(photo)

    Button(win, text='Quit', command=win.quit, bg='beige').pack(fill=X)
    return win, savephotos

if __name__ == '__main__':
    imgdir = (len(sys.argv) > 1 and sys.argv[1]) or 'images'
    main, save = viewer(imgdir, kind=Tk)
    main.mainloop()

Figure 8-48 shows the results of applying a fixed size to our buttons; all are the same size now, using a size taken from the images themselves. The effect is to display all thumbnails as same-size tiles regardless of their shape, so they are easier to view. Naturally, other layout schemes are possible as well; experiment with some of the configuration options in this code on your own to see their effect on the display.

Figure 8-48. Fixed-size thumbnail selection GUI, row frames

The thumbnail viewer scripts presented in this section work well for reasonably sized image directories, and you can use smaller thumbnail size settings for larger image collections. Perhaps the biggest limitation of these programs, though, is that the thumbnail windows they create will become too large to handle (or display at all) if the image directory contains very many files.

Even with the sample images directory used for this book, we lost the Quit button at the bottom of the display in the last two figures because there are too many thumbnail images to show. To illustrate the difference, the original Example 8-45 packs the Quit button first for this very reason—so it is clipped last, after all thumbnails, and thus remains visible when there are many photos. We could do a similar thing for the other versions, but we’d still lose thumbnails if there were too many. A directory from your camera with many images might similarly produce a window too large to fit on your computer’s screen.

To do better, we could arrange the thumbnails on a widget that supports scrolling. The open source Pmw package includes a handy scrolled frame that may help. Moreover, the standard tkinter Canvas widget gives us more control over image displays (including placement by absolute pixel coordinates) and supports horizontal and vertical scrolling of its content.

In fact, in the next chapter, we’ll code one final extension to our script which does just that—it displays thumbnails in a scrolled canvas, and so it handles large collections much better. Its thumbnail buttons are fixed-size as in our last example here, but are positioned at computed coordinates. I’ll defer further details here, though, because we’ll study that extension in conjunction with canvases in the next chapter. And in Chapter 11, we’ll apply this technique to an even more full-featured image program called PyPhoto.

To learn how these programs do their jobs, though, we need to move on to the next chapter, and the second half of our widget tour.