Thinking in Tkinter (2005).pdf

Thinking in Tkinter

by Stephen Ferg (steve@ ferg.org)

revised: 2005-07-17

This file contains the source code for all of the files in the Thinking in Tkinter

series.

If you print this file with a small font, you should be able to print it in portrait mode without truncating

the ends of any of the lines of code. If you print it, and find that you ARE truncating lines of code,

consider printing it in a smaller font, or printing it in landscape mode.

Printed size is approximately 40 to 60 pages, depending on your print settings. You can see what the

printed result will look like, and how many pages it will require, by looking at the results of Print Preview

before you actually print the file.

tt000.py

Subject: "Thinking in Tkinter"

Author : Stephen Ferg (steve@ferg.org)

About " Thinking In Tkinter "

I've been trying to teach myself Tkinter out of various books, and I'm finding it more difficult than I

think it should be.

The problem is that the authors of the books want to rush into telling me about all of the widgets in the

Tkinter toolbox, but never really pause to explain basic concepts. They don't explain how to "think in

Tkinter".

Here are a few short programs that begin to explain how to think in Tkinter. In them, I don't attempt to

catalog all of the types of widgets, attributes, and methods that are available in Tkinter. and I certainly

don't try to provide a comprehensive introduction to Tkinter. I just try to get you started down the road

of understanding some basic Tkinter concepts.

Note that the discussion is devoted exclusively to the Tkinter pack (or "packer") geometry manager.

There is no discussion of the grid or place geometry managers.

The Four Basic Gui-programming Tasks

When you develop a user interface (UI) there is a standard set of tasks that you must accomplish.

1) You must specify how you want the UI to *look*. That is, you must write code that determines what

the user will see on the computer screen.

1 of 53

Thinking in Tkinter

2) You must decide what you want the UI to *do*. That is, you must write routines that accomplish the

tasks of the program.

3) You must associate the "looking" with the "doing". That is, you must write code that associates the

things that the user sees on the screen with the routines that you have written to perform the

program's tasks.

4) finally, you must write code that sits and waits for input from the user.

Some Gui-programming Jargon

GUI (graphical user interface) programming has some special jargon associated with these basic tasks.

1) We specify how we want a GUI to look by describing the "widgets" that we want it to display, and

their spatial relationships (i.e. whether one widget is above or below, or to the right or left, of other

widgets). The word "widget" is a nonsense word that has become the common term for "graphical user

interface component". Widgets include things such as windows, buttons, menus and menu items, icons,

drop-down lists, scroll bars, and so on.

2) The routines that actually do the work of the GUI are called "callback handlers" or "event handlers".

"Events" are input events such as mouse clicks or presses of a key on the keyboard. These routines are

called "handlers" because they "handle" (that is, respond to) such events.

3) Associating an event handler with a widget is called "binding". Roughly, the process of binding

involves associating three different things:

(a) a type of event (e.g. a click of the left mouse button,

or a press of the ENTER key on the keyboard),

(b) a widget (e.g. a button), and

For example, we might bind (a) a single-click of the left mouse button on (b) the "CLOSE" button/widget

on the screen to (c) the "closeProgram" routine, which closes the window and shuts down the program.

4) The code that sits and waits for input is called the "event loop".

About The Event Loop

If you believe the movies, every small town has a little old lady who spends all of her time at her front

window, just WATCHING. She sees everything that goes on in the neighborhood. A lot of what she sees

is uninteresting of course -- just people going to and fro in the street. But some of it is interesting -- like

a big fight between the newly-wed couple in the house across the street. When interesting events

happen, the watchdog lady immediately is on the phone with the news to the police or to her neighbors.

The event loop is a lot like this watchdog lady. The event loop spends all of its time watching events go

by, and it sees all of them. Most of the events are uninteresting, and when it sees them, it does

nothing. But when it sees something interesting -- an event that it knows is interesting, because an

event handler has been bound to the event -- then it immediately calls up the event handler and lets it

know that the event has happened.

Program Behavior

This program eases you into user-interace programming by showing how these basic concepts are

2 of 53

Thinking in Tkinter

implemented in a very simple program. This program doesn't use Tkinter or any form of GUI

programming. It just puts up a menu on the console, and gets simple keyboard input. Even so, as you

can see, it does the four basic tasks of user-interface programming.

[revised: 2003-02-23]

Program Source Code

#----- task 2: define the event handler routines ---------------------

def handle_A():

print "Wrong! Try again!"

def handle_B():

print "Absolutely right! Trillium is a kind of flower!"

def handle_C():

print "Wrong! Try again!"

# ------------ task 1: define the appearance of the screen ------------

print "\n"*100 # clear the screen

print " VERY CHALLENGING GUESSING GAME"

print "========================================================"

print "Press the letter of your answer, then the ENTER key."

print " A. Animal"

print " B. Vegetable"

print " C. Mineral"

print " X. Exit from this program"

print "========================================================"

print "What kind of thing is 'Trillium'?"

# ---- task 4: the event loop. We loop forever, observing events. ---

while 1:

# We observe the next event

answer = raw_input().upper()

# -------------------------------------------------------

# Task 3: Associate interesting keyboard events with their

# event handlers. A simple form of binding.

# -------------------------------------------------------

if answer == "A": handle_A()

if answer == "B": handle_B()

if answer == "C": handle_C()

if answer == "X":

# clear the screen and exit the event loop

print "\n"*100

break

# Note that any other events are uninteresting, and are ignored

3 of 53

Thinking in Tkinter

tt010.py

The Simplest Possible Tkinter Program -- Three Statements!

Of the four basic GUI tasks that we discussed in the last program, this program does only one -- it runs

the event loop.

(1) The first statement imports Tkinter, so that it is available for use. Note that the form of the import

("from Tkinter import *") means that we will not have to qualify anything that we get from Tkinter with

a "Tkinter." prefix.

(2) The second statement creates a "toplevel" window. Technically, what the the second statement is

doing, is creating an instance of the class "Tkinter.Tk".

This toplevel window is the highest-level GUI component in any Tkinter application. By convention, the

toplevel window is usually named "root".

(3) The third statement executes the "mainloop" (that is, the event loop) method of the "root" object.

As the mainloop runs, it waits for events to happen in root. If an event occurs, then it is handled and

the loop continues running, waiting for the next evernt. The loop continues to execute until a "destroy"

event happens to the root window. A "destroy" event is one that closes a window. When the root is

destroyed, the window is closed and the event loop is exited.

Program Behavior

When you run this program, you will see that (thanks to Tk) the toplevel window automatically comes

furnished with widgets to minimize, maximize, and close the window. Try them -- you'll see that they

really do work.

Clicking on the "close" widget (the "x" in a box, at the right of the title bar) generates a "destroy"

event. The destroy event terminates the main event loop. And since there are no statements after

"root.mainloop()", the program has nothing more to do, and ends.

[revised: 2003-02-23]

Program Source Code

from Tkinter import * ### (1)

root = Tk() ### (2)

root.mainloop() ### (3)

4 of 53

Thinking in Tkinter

tt020.py

Now we tackle another of the four main GUI tasks -- specifying how the GUI should look.

In this program, we introduce three major concepts of Tkinter programming:

* creating a GUI object and associating it with its parent

* packing

* containers vs. widgets

From now on, I'm going to distinguish between a container component and a widget. As I will be using

the terms, a "widget" is a GUI component that (usually) is visible and does things. A "container" in

contrast is simply a container -- a basket, as it were -- into which we can put widgets.

Tkinter provides a number of containers. "Canvas" is a container for drawing applications. The most

frequently used container is a "frame".

Frames are provided by Tkinter in a class called "Frame". An expression like:

Frame(myParent)

creates an instance of the Frame class (that is, it creates a frame), and associates the frame instance

with its parent, myParent. Or another way of looking at it is: such an expression adds a child frame to

the myParent component.

So in this program, statement (1):

myContainer1 = Frame(myParent)

creates a frame whose parent is myParent (that is, root), and gives it the name "myContainer1". In

short, it creates a container into which we can put widgets. (We won't put any widgets into in this

program. We'll do that in later programs.)

Note that the parent/child relationship here is a LOGICAL one, not a visual one. This relationship exists

to support such things as the destroy event -- so that when a parent component (such as the root) is

destroyed, the parent knows who its children are, and can destroy them before destroying itself.

(2) The next statement "packs" myContainer1.

myContainer1.pack()

Simply put, "packing" is a process of setting up a VISUAL relationship between a GUI component and its

parent. If you don't pack a component, you will never see it.

"Pack" invokes the Tkinter "pack" geometry manager. A geometry manager is essentially an API -- a

way of talking to Tkinter -- for telling Tkinter how you want containers and widgets to be visually

presented. Tkinter supports three geometry managers: pack, grid, and place. Pack (and to a lesser

extent) grid are the most widely used, because they are the easiest to use. All of the examples in

5 of 53

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: