tkinter --- Tcl/Tk的Python接口

源代码: Lib/tkinter/

The tkinter package ("Tk interface") is the standard Python interface to the Tk GUI toolkit. Both Tk and tkinter are available on most Unix platforms, as well as on Windows systems. (Tk itself is not part of Python; it is maintained at ActiveState.)

在命令行中运行 python -m tkinter,应该会弹出一个Tk界面的窗口,表明 tkinter 包已经正确安装,而且告诉你 Tcl/Tk 的版本号,通过这个版本号,你就可以参考对应的 Tcl/Tk 文档了。



Python Tkinter 资源

The Python Tkinter Topic Guide 提供了在 Python 中使用 Tk 的很多信息, 同时包含了Tk其他信息的链接。



Tkinter 8.5 参考:一个Python图形用户界面


Tkinter docs from effbot 提供的 tkinter 在线参考资料。

使用 Python 编程

由 Mark Lutz 所著的书籍,对 Tkinter 进行了完美的介绍。

为繁忙的 Python 开发者所准备的现代 Tkinter

由 Mark Rozerman 所著的关于如何使用 Python 和 Tkinter 来搭建有吸引力的和现代化的图形用户界面的书籍

Python 和 Tkinter 编程

作者: John Grayson (ISBN 1-884777-81-3).

Tcl/Tk 文档:

Tk 命令

多数命令以 tkinter 或者 tkinter.ttk 类的形式存在。改变 '8.6' 以匹配所安装的 Tcl/Tk 版本。

Tcl/Tk 最新手册页面 上面最新的 Tcl/Tk 手册。

ActiveState Tcl 主页

Tk/Tcl 的多数开发工作发生在 ActiveState 。

Tcl 及 Tk 工具集

由 Tcl 发明者 John Ousterhout 所著的书籍。

` Tcl 和 Tk 编程实战 <>`_

Brent Welch 所著的百科全局式书籍。

Tkinter 模块

在大多数时候你只需要 tkinter 就足够了,但也有一些额外的模块可供使用。Tk 接口位于一个名字 _tkinter 的二进制模块当中。此模块包含了低层级的 Tk 接口,它不应该被应用程序员所直接使用。它通常是一个共享库(或 DLL),但在某些情况下也可能被静态链接到 Python 解释器。

除了Tk接口, tkinter 也包含了若干 Python 模块,tkinter.constants 是其中最重要的。导入 tkinter 会自动导入 tkinter.constants ,所以,要使用 Tkinter 通常你只需要一条简单的 import 语句:

import tkinter


from tkinter import *
class tkinter.Tk(screenName=None, baseName=None, className='Tk', useTk=1)

Tk 类被初始化时无参数。此时会创建一个 Tk 顶级控件,通常是应用程序的主窗口。每个实例都有自己关联的 Tcl 解释器。

tkinter.Tcl(screenName=None, baseName=None, className='Tk', useTk=0)

Tcl() 函数是一个工厂函数,它创建的对象与 Tk 类创建的对象非常相似,只是它不初始化 Tk 子系统。 在不想创建或无法创建(如没有 X Server 的 Unix/Linux 系统)额外的顶层窗口的环境中驱动 Tcl 解释器时,这一点非常有用。 由 Tcl() 对象创建的对象可以通过调用其 loadtk() 方法来创建顶层窗口(并初始化 Tk 子系统)。



Text widget with a vertical scroll bar built in.






Common dialogs to allow the user to specify a file to open or save.


Utilities to help work with fonts.


Access to standard Tk dialog boxes.


Basic dialogs and convenience functions.


Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.


Turtle graphics in a Tk window.

Tkinter Life Preserver

This section is not designed to be an exhaustive tutorial on either Tk or Tkinter. Rather, it is intended as a stop gap, providing some introductory orientation on the system.


  • Tk was written by John Ousterhout while at Berkeley.

  • Tkinter was written by Steen Lumholt and Guido van Rossum.

  • This Life Preserver was written by Matt Conway at the University of Virginia.

  • The HTML rendering, and some liberal editing, was produced from a FrameMaker version by Ken Manheimer.

  • Fredrik Lundh elaborated and revised the class interface descriptions, to get them current with Tk 4.2.

  • Mike Clarkson converted the documentation to LaTeX, and compiled the User Interface chapter of the reference manual.

How To Use This Section

This section is designed in two parts: the first half (roughly) covers background material, while the second half can be taken to the keyboard as a handy reference.

When trying to answer questions of the form "how do I do blah", it is often best to find out how to do "blah" in straight Tk, and then convert this back into the corresponding tkinter call. Python programmers can often guess at the correct Python command by looking at the Tk documentation. This means that in order to use Tkinter, you will have to know a little bit about Tk. This document can't fulfill that role, so the best we can do is point you to the best documentation that exists. Here are some hints:

  • The authors strongly suggest getting a copy of the Tk man pages. Specifically, the man pages in the manN directory are most useful. The man3 man pages describe the C interface to the Tk library and thus are not especially helpful for script writers.

  • Addison-Wesley publishes a book called Tcl and the Tk Toolkit by John Ousterhout (ISBN 0-201-63337-X) which is a good introduction to Tcl and Tk for the novice. The book is not exhaustive, and for many details it defers to the man pages.

  • tkinter/ is a last resort for most, but can be a good place to go when nothing else makes sense.

A Simple Hello World Program

import tkinter as tk

class Application(tk.Frame):
    def __init__(self, master=None):
        self.master = master

    def create_widgets(self):
        self.hi_there = tk.Button(self)
        self.hi_there["text"] = "Hello World\n(click me)"
        self.hi_there["command"] = self.say_hi

        self.quit = tk.Button(self, text="QUIT", fg="red",

    def say_hi(self):
        print("hi there, everyone!")

root = tk.Tk()
app = Application(master=root)

A (Very) Quick Look at Tcl/Tk

The class hierarchy looks complicated, but in actual practice, application programmers almost always refer to the classes at the very bottom of the hierarchy.


  • These classes are provided for the purposes of organizing certain functions under one namespace. They aren't meant to be instantiated independently.

  • The Tk class is meant to be instantiated only once in an application. Application programmers need not instantiate one explicitly, the system creates one whenever any of the other classes are instantiated.

  • The Widget class is not meant to be instantiated, it is meant only for subclassing to make "real" widgets (in C++, this is called an 'abstract class').

To make use of this reference material, there will be times when you will need to know how to read short passages of Tk and how to identify the various parts of a Tk command. (See section Mapping Basic Tk into Tkinter for the tkinter equivalents of what's below.)

Tk scripts are Tcl programs. Like all Tcl programs, Tk scripts are just lists of tokens separated by spaces. A Tk widget is just its class, the options that help configure it, and the actions that make it do useful things.

To make a widget in Tk, the command is always of the form:

classCommand newPathname options

denotes which kind of widget to make (a button, a label, a menu...)


is the new name for this widget. All names in Tk must be unique. To help enforce this, widgets in Tk are named with pathnames, just like files in a file system. The top level widget, the root, is called . (period) and children are delimited by more periods. For example, .myApp.controlPanel.okButton might be the name of a widget.


configure the widget's appearance and in some cases, its behavior. The options come in the form of a list of flags and values. Flags are preceded by a '-', like Unix shell command flags, and values are put in quotes if they are more than one word.


button   .fred   -fg red -text "hi there"
   ^       ^     \______________________/
   |       |                |
 class    new            options
command  widget  (-opt val -opt val ...)

Once created, the pathname to the widget becomes a new command. This new widget command is the programmer's handle for getting the new widget to perform some action. In C, you'd express this as someAction(fred, someOptions), in C++, you would express this as fred.someAction(someOptions), and in Tk, you say:

.fred someAction someOptions

Note that the object name, .fred, starts with a dot.

As you'd expect, the legal values for someAction will depend on the widget's class: .fred disable works if fred is a button (fred gets greyed out), but does not work if fred is a label (disabling of labels is not supported in Tk).

The legal values of someOptions is action dependent. Some actions, like disable, require no arguments, others, like a text-entry box's delete command, would need arguments to specify what range of text to delete.

Mapping Basic Tk into Tkinter

Class commands in Tk correspond to class constructors in Tkinter.

button .fred                =====>  fred = Button()

The master of an object is implicit in the new name given to it at creation time. In Tkinter, masters are specified explicitly.

button .panel.fred          =====>  fred = Button(panel)

The configuration options in Tk are given in lists of hyphened tags followed by values. In Tkinter, options are specified as keyword-arguments in the instance constructor, and keyword-args for configure calls or as instance indices, in dictionary style, for established instances. See section Setting Options on setting options.

button .fred -fg red        =====>  fred = Button(panel, fg="red")
.fred configure -fg red     =====>  fred["fg"] = red
                            OR ==>  fred.config(fg="red")

In Tk, to perform an action on a widget, use the widget name as a command, and follow it with an action name, possibly with arguments (options). In Tkinter, you call methods on the class instance to invoke actions on the widget. The actions (methods) that a given widget can perform are listed in tkinter/

.fred invoke                =====>  fred.invoke()

To give a widget to the packer (geometry manager), you call pack with optional arguments. In Tkinter, the Pack class holds all this functionality, and the various forms of the pack command are implemented as methods. All widgets in tkinter are subclassed from the Packer, and so inherit all the packing methods. See the tkinter.tix module documentation for additional information on the Form geometry manager.

pack .fred -side left       =====>  fred.pack(side="left")

Handy Reference

Setting Options

Options control things like the color and border width of a widget. Options can be set in three ways:

At object creation time, using keyword arguments
fred = Button(self, fg="red", bg="blue")
After object creation, treating the option name like a dictionary index
fred["fg"] = "red"
fred["bg"] = "blue"
Use the config() method to update multiple attrs subsequent to object creation
fred.config(fg="red", bg="blue")

For a complete explanation of a given option and its behavior, see the Tk man pages for the widget in question.

Note that the man pages list "STANDARD OPTIONS" and "WIDGET SPECIFIC OPTIONS" for each widget. The former is a list of options that are common to many widgets, the latter are the options that are idiosyncratic to that particular widget. The Standard Options are documented on the options(3) man page.

No distinction between standard and widget-specific options is made in this document. Some options don't apply to some kinds of widgets. Whether a given widget responds to a particular option depends on the class of the widget; buttons have a command option, labels do not.

The options supported by a given widget are listed in that widget's man page, or can be queried at runtime by calling the config() method without arguments, or by calling the keys() method on that widget. The return value of these calls is a dictionary whose key is the name of the option as a string (for example, 'relief') and whose values are 5-tuples.

Some options, like bg are synonyms for common options with long names (bg is shorthand for "background"). Passing the config() method the name of a shorthand option will return a 2-tuple, not 5-tuple. The 2-tuple passed back will contain the name of the synonym and the "real" option (such as ('bg', 'background')).




















>>> print(fred.config())
{'relief': ('relief', 'relief', 'Relief', 'raised', 'groove')}

Of course, the dictionary printed will include all the options available and their values. This is meant only as an example.

The Packer

The packer is one of Tk's geometry-management mechanisms. Geometry managers are used to specify the relative positioning of widgets within their container - their mutual master. In contrast to the more cumbersome placer (which is used less commonly, and we do not cover here), the packer takes qualitative relationship specification - above, to the left of, filling, etc - and works everything out to determine the exact placement coordinates for you.

The size of any master widget is determined by the size of the "slave widgets" inside. The packer is used to control where slave widgets appear inside the master into which they are packed. You can pack widgets into frames, and frames into other frames, in order to achieve the kind of layout you desire. Additionally, the arrangement is dynamically adjusted to accommodate incremental changes to the configuration, once it is packed.

Note that widgets do not appear until they have had their geometry specified with a geometry manager. It's a common early mistake to leave out the geometry specification, and then be surprised when the widget is created but nothing appears. A widget will appear only after it has had, for example, the packer's pack() method applied to it.

The pack() method can be called with keyword-option/value pairs that control where the widget is to appear within its container, and how it is to behave when the main application window is resized. Here are some examples:

fred.pack()                     # defaults to side = "top"

Packer Options

For more extensive information on the packer and the options that it can take, see the man pages and page 183 of John Ousterhout's book.


Anchor type. Denotes where the packer is to place each slave in its parcel.


Boolean, 0 or 1.


Legal values: 'x', 'y', 'both', 'none'.

ipadx 和 ipady

A distance - designating internal padding on each side of the slave widget.

padx 和 pady

A distance - designating external padding on each side of the slave widget.


Legal values are: 'left', 'right', 'top', 'bottom'.

Coupling Widget Variables

The current-value setting of some widgets (like text entry widgets) can be connected directly to application variables by using special options. These options are variable, textvariable, onvalue, offvalue, and value. This connection works both ways: if the variable changes for any reason, the widget it's connected to will be updated to reflect the new value.

Unfortunately, in the current implementation of tkinter it is not possible to hand over an arbitrary Python variable to a widget through a variable or textvariable option. The only kinds of variables for which this works are variables that are subclassed from a class called Variable, defined in tkinter.

There are many useful subclasses of Variable already defined: StringVar, IntVar, DoubleVar, and BooleanVar. To read the current value of such a variable, call the get() method on it, and to change its value you call the set() method. If you follow this protocol, the widget will always track the value of the variable, with no further intervention on your part.


import tkinter as tk

class App(tk.Frame):
    def __init__(self, master):

        self.entrythingy = tk.Entry()

        # Create the application variable.
        self.contents = tk.StringVar()
        # Set it to some value.
        self.contents.set("this is a variable")
        # Tell the entry widget to watch this variable.
        self.entrythingy["textvariable"] = self.contents

        # Define a callback for when the user hits return.
        # It prints the current value of the variable.

    def print_contents(self, event):
        print("Hi. The current entry content is:",

root = tk.Tk()
myapp = App(root)

The Window Manager

In Tk, there is a utility command, wm, for interacting with the window manager. Options to the wm command allow you to control things like titles, placement, icon bitmaps, and the like. In tkinter, these commands have been implemented as methods on the Wm class. Toplevel widgets are subclassed from the Wm class, and so can call the Wm methods directly.

To get at the toplevel window that contains a given widget, you can often just refer to the widget's master. Of course if the widget has been packed inside of a frame, the master won't represent a toplevel window. To get at the toplevel window that contains an arbitrary widget, you can call the _root() method. This method begins with an underscore to denote the fact that this function is part of the implementation, and not an interface to Tk functionality.

Here are some examples of typical usage:

import tkinter as tk

class App(tk.Frame):
    def __init__(self, master=None):

# create the application
myapp = App()

# here are method calls to the window manager class
myapp.master.title("My Do-Nothing Application")
myapp.master.maxsize(1000, 400)

# start the program

Tk Option Data Types


Legal values are points of the compass: "n", "ne", "e", "se", "s", "sw", "w", "nw", and also "center".


There are eight built-in, named bitmaps: 'error', 'gray25', 'gray50', 'hourglass', 'info', 'questhead', 'question', 'warning'. To specify an X bitmap filename, give the full path to the file, preceded with an @, as in "@/usr/contrib/bitmap/gumby.bit".


You can pass integers 0 or 1 or the strings "yes" or "no".

callback -- 回调

This is any Python function that takes no arguments. For example:

def print_it():
    print("hi there")
fred["command"] = print_it

Colors can be given as the names of X colors in the rgb.txt file, or as strings representing RGB values in 4 bit: "#RGB", 8 bit: "#RRGGBB", 12 bit" "#RRRGGGBBB", or 16 bit "#RRRRGGGGBBBB" ranges, where R,G,B here represent any legal hex digit. See page 160 of Ousterhout's book for details.


The standard X cursor names from cursorfont.h can be used, without the XC_ prefix. For example to get a hand cursor (XC_hand2), use the string "hand2". You can also specify a bitmap and mask file of your own. See page 179 of Ousterhout's book.


Screen distances can be specified in either pixels or absolute distances. Pixels are given as numbers and absolute distances as strings, with the trailing character denoting units: c for centimetres, i for inches, m for millimetres, p for printer's points. For example, 3.5 inches is expressed as "3.5i".


Tk uses a list font name format, such as {courier 10 bold}. Font sizes with positive numbers are measured in points; sizes with negative numbers are measured in pixels.


This is a string of the form widthxheight, where width and height are measured in pixels for most widgets (in characters for widgets displaying text). For example: fred["geometry"] = "200x100".


Legal values are the strings: "left", "center", "right", and "fill".


This is a string with four space-delimited elements, each of which is a legal distance (see above). For example: "2 3 4 5" and "3i 2i 4.5i 2i" and "3c 2c 4c 10.43c" are all legal regions.


Determines what the border style of a widget will be. Legal values are: "raised", "sunken", "flat", "groove", and "ridge".


This is almost always the set() method of some scrollbar widget, but can be any widget method that takes a single argument.


Must be one of: "none", "char", or "word".

Bindings and Events

The bind method from the widget command allows you to watch for certain events and to have a callback function trigger when that event type occurs. The form of the bind method is:

def bind(self, sequence, func, add=''):


sequence -- 序列

is a string that denotes the target kind of event. (See the bind man page and page 201 of John Ousterhout's book for details).


is a Python function, taking one argument, to be invoked when the event occurs. An Event instance will be passed as the argument. (Functions deployed this way are commonly known as callbacks.)


is optional, either '' or '+'. Passing an empty string denotes that this binding is to replace any other bindings that this event is associated with. Passing a '+' means that this function is to be added to the list of functions bound to this event type.


def turn_red(self, event):
    event.widget["activeforeground"] = "red"

self.button.bind("<Enter>", self.turn_red)

Notice how the widget field of the event is being accessed in the turn_red() callback. This field contains the widget that caught the X event. The following table lists the other event fields you can access, and how they are denoted in Tk, which can be useful when referring to the Tk man pages.


Tkinter Event Field


Tkinter Event Field

































The index Parameter

A number of widgets require "index" parameters to be passed. These are used to point at a specific place in a Text widget, or to particular characters in an Entry widget, or to particular menu items in a Menu widget.

Entry widget indexes (index, view index, etc.)

Entry widgets have options that refer to character positions in the text being displayed. You can use these tkinter functions to access these special points in text widgets:

Text widget indexes

The index notation for Text widgets is very rich and is best described in the Tk man pages.

Menu indexes (menu.invoke(), menu.entryconfig(), etc.)

Some options and methods for menus manipulate specific menu entries. Anytime a menu index is needed for an option or a parameter, you may pass in:

  • an integer which refers to the numeric position of the entry in the widget, counted from the top, starting with 0;

  • the string "active", which refers to the menu position that is currently under the cursor;

  • the string "last" which refers to the last menu item;

  • An integer preceded by @, as in @6, where the integer is interpreted as a y pixel coordinate in the menu's coordinate system;

  • the string "none", which indicates no menu entry at all, most often used with menu.activate() to deactivate all entries, and finally,

  • a text string that is pattern matched against the label of the menu entry, as scanned from the top of the menu to the bottom. Note that this index type is considered after all the others, which means that matches for menu items labelled last, active, or none may be interpreted as the above literals, instead.


Images of different formats can be created through the corresponding subclass of tkinter.Image:

  • BitmapImage for images in XBM format.

  • PhotoImage for images in PGM, PPM, GIF and PNG formats. The latter is supported starting with Tk 8.6.

Either type of image is created through either the file or the data option (other options are available as well).

The image object can then be used wherever an image option is supported by some widget (e.g. labels, buttons, menus). In these cases, Tk will not keep a reference to the image. When the last Python reference to the image object is deleted, the image data is deleted as well, and Tk will display an empty box wherever the image was used.


The Pillow package adds support for formats such as BMP, JPEG, TIFF, and WebP, among others.

File Handlers

Tk allows you to register and unregister a callback function which will be called from the Tk mainloop when I/O is possible on a file descriptor. Only one handler may be registered per file descriptor. Example code:

import tkinter
widget = tkinter.Tk()
mask = tkinter.READABLE | tkinter.WRITABLE, mask, callback)

This feature is not available on Windows.

Since you don't know how many bytes are available for reading, you may not want to use the BufferedIOBase or TextIOBase read() or readline() methods, since these will insist on reading a predefined number of bytes. For sockets, the recv() or recvfrom() methods will work fine; for other files, use raw reads or, maxbytecount)., mask, func)

Registers the file handler callback function func. The file argument may either be an object with a fileno() method (such as a file or socket object), or an integer file descriptor. The mask argument is an ORed combination of any of the three constants below. The callback is called as follows:

callback(file, mask)

Unregisters a file handler.


Constants used in the mask arguments.