:mod:`Tkinter` --- Python interface to Tcl/Tk

=============================================

.. module:: Tkinter

   :synopsis: Interface to Tcl/Tk for graphical user interfaces

.. moduleauthor:: Guido van Rossum <guido@Python.org>

The :mod:`Tkinter` module ("Tk interface") is the standard Python interface to

the Tk GUI toolkit.  Both Tk and :mod:`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.)

.. note::

   :mod:`Tkinter` has been renamed to :mod:`tkinter` in Python 3.0.  The

   :term:`2to3` tool will automatically adapt imports when converting your

   sources to 3.0.

.. seealso::

   `Python Tkinter Resources <http://www.python.org/topics/tkinter/>`_

      The Python Tkinter Topic Guide provides a great deal of information on using Tk

      from Python and links to other sources of information on Tk.

   `An Introduction to Tkinter <http://www.pythonware.com/library/an-introduction-to-tkinter.htm>`_

      Fredrik Lundh's on-line reference material.

   `Tkinter reference: a GUI for Python <http://infohost.nmt.edu/tcc/help/pubs/lang.html>`_

      On-line reference material.

   `Tkinter for JPython <http://jtkinter.sourceforge.net>`_

      The Jython interface to Tkinter.

   `Python and Tkinter Programming <http://www.amazon.com/exec/obidos/ASIN/1884777813>`_

      The book by John Grayson (ISBN 1-884777-81-3).

Tkinter Modules

---------------

Most of the time, the :mod:`Tkinter` module is all you really need, but a number

of additional modules are available as well.  The Tk interface is located in a

binary module named :mod:`_tkinter`. This module contains the low-level

interface to Tk, and should never be used directly by application programmers.

It is usually a shared library (or DLL), but might in some cases be statically

linked with the Python interpreter.

In addition to the Tk interface module, :mod:`Tkinter` includes a number of

Python modules. The two most important modules are the :mod:`Tkinter` module

itself, and a module called :mod:`Tkconstants`. The former automatically imports

the latter, so to use Tkinter, all you need to do is to import one module::

   import Tkinter

Or, more often::

   from Tkinter import *

.. class:: Tk(screenName=None, baseName=None, className='Tk', useTk=1)

   The :class:`Tk` class is instantiated without arguments. This creates a toplevel

   widget of Tk which usually is the main window of an application. Each instance

   has its own associated Tcl interpreter.

   .. FIXME: The following keyword arguments are currently recognized:

   .. versionchanged:: 2.4

      The *useTk* parameter was added.

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

   The :func:`Tcl` function is a factory function which creates an object much like

   that created by the :class:`Tk` class, except that it does not initialize the Tk

   subsystem.  This is most often useful when driving the Tcl interpreter in an

   environment where one doesn't want to create extraneous toplevel windows, or

   where one cannot (such as Unix/Linux systems without an X server).  An object

   created by the :func:`Tcl` object can have a Toplevel window created (and the Tk

   subsystem initialized) by calling its :meth:`loadtk` method.

   .. versionadded:: 2.4

Other modules that provide Tk support include:

:mod:`ScrolledText`

   Text widget with a vertical scroll bar built in.

:mod:`tkColorChooser`

   Dialog to let the user choose a color.

:mod:`tkCommonDialog`

   Base class for the dialogs defined in the other modules listed here.

:mod:`tkFileDialog`

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

:mod:`tkFont`

   Utilities to help work with fonts.

:mod:`tkMessageBox`

   Access to standard Tk dialog boxes.

:mod:`tkSimpleDialog`

   Basic dialogs and convenience functions.

:mod:`Tkdnd`

   Drag-and-drop support for :mod:`Tkinter`. This is experimental and should become

   deprecated when it is replaced  with the Tk DND.

:mod:`turtle`

   Turtle graphics in a Tk window.

These have been renamed as well in Python 3.0; they were all made submodules of

the new ``tkinter`` package.

Tkinter Life Preserver

----------------------

.. sectionauthor:: Matt Conway

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.

Credits:

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

* Tk was written by John Ousterhout while at Berkeley.

* 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 :mod:`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.

* :file:`Tkinter.py` is a last resort for most, but can be a good place to go

  when nothing else makes sense.

.. seealso::

   `ActiveState Tcl Home Page <http://tcl.activestate.com/>`_

      The Tk/Tcl development is largely taking place at ActiveState.

   `Tcl and the Tk Toolkit <http://www.amazon.com/exec/obidos/ASIN/020163337X>`_

      The book by John Ousterhout, the inventor of Tcl .

   `Practical Programming in Tcl and Tk <http://www.amazon.com/exec/obidos/ASIN/0130220280>`_

      Brent Welch's encyclopedic book.

A Simple Hello World Program

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

::

   from Tkinter import *

   class Application(Frame):

       def say_hi(self):

           print "hi there, everyone!"

       def createWidgets(self):

           self.QUIT = Button(self)

           self.QUIT["text"] = "QUIT"

           self.QUIT["fg"]   = "red"

           self.QUIT["command"] =  self.quit

           self.QUIT.pack({"side": "left"})

           self.hi_there = Button(self)

           self.hi_there["text"] = "Hello",

           self.hi_there["command"] = self.say_hi

           self.hi_there.pack({"side": "left"})

       def __init__(self, master=None):

           Frame.__init__(self, master)

           self.pack()

           self.createWidgets()

   root = Tk()

   app = Application(master=root)

   app.mainloop()

   root.destroy()

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.

Notes:

* These classes are provided for the purposes of organizing certain functions

  under one namespace. They aren't meant to be instantiated independently.

* The :class:`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 :class:`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 :ref:`tkinter-basic-mapping` for the

:mod:`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

*classCommand*

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

*newPathname*

   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.

*options*

   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.

For example::

   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.

.. _tkinter-basic-mapping:

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

:ref:`tkinter-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 the Tkinter.py

module. ::

   .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

:mod:`Tkinter` are subclassed from the Packer, and so inherit all the packing

methods. See the :mod:`Tix` module documentation for additional information on

the Form geometry manager. ::

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

How Tk and Tkinter are Related

------------------------------

From the top down:

Your App Here (Python)

   A Python application makes a :mod:`Tkinter` call.

Tkinter (Python Module)

   This call (say, for example, creating a button widget), is implemented in the

   *Tkinter* module, which is written in Python.  This Python function will parse

   the commands and the arguments and convert them into a form that makes them look

   as if they had come from a Tk script instead of a Python script.

tkinter (C)

   These commands and their arguments will be passed to a C function in the

   *tkinter* - note the lowercase - extension module.

Tk Widgets (C and Tcl)

   This C function is able to make calls into other C modules, including the C

   functions that make up the Tk library.  Tk is implemented in C and some Tcl.

   The Tcl part of the Tk widgets is used to bind certain default behaviors to

   widgets, and is executed once at the point where the Python :mod:`Tkinter`

   module is imported. (The user never sees this stage).

Tk (C)

   The Tk part of the Tk Widgets implement the final mapping to ...

Xlib (C)

   the Xlib library to draw graphics on the screen.

Handy Reference

---------------

.. _tkinter-setting-options:

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 :manpage:`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 :meth:`config` method without

arguments, or by calling the :meth:`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')``).

+-------+---------------------------------+--------------+

| Index | Meaning                         | Example      |

+=======+=================================+==============+

| 0     | option name                     | ``'relief'`` |

+-------+---------------------------------+--------------+

| 1     | option name for database lookup | ``'relief'`` |

+-------+---------------------------------+--------------+

| 2     | option class for database       | ``'Relief'`` |

|       | lookup                          |              |

+-------+---------------------------------+--------------+

| 3     | default value                   | ``'raised'`` |

+-------+---------------------------------+--------------+

| 4     | current value                   | ``'groove'`` |

+-------+---------------------------------+--------------+

Example::

   >>> 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

^^^^^^^^^^

.. index:: single: packing (widgets)

The packer is one of Tk's geometry-management mechanisms.    Geometry managers

are used to specify the relative positioning of the 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

:meth:`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"

   fred.pack(side = "left")

   fred.pack(expand = 1)

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 

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

expand

   Boolean, ``0`` or ``1``.

fill

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

ipadx and ipady

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

padx and pady

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

side

   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 :mod:`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 the :mod:`Tkinter` module.

There are many useful subclasses of Variable already defined:

:class:`StringVar`, :class:`IntVar`, :class:`DoubleVar`, and