tkinter questions: behavior of StringVar, etc

Eric Brunel eric.brunel at nospam-pragmadev.com
Mon Mar 30 09:37:09 CEST 2009


Alan G Isaac wrote:
> I'm a complete newbie to GUI.
> I have a couple questions about tkinter.
>
> 1. Where is the list of changes
>     in Python 3's tkinter?

I'll let someone else answer this as I don't use Python 3 myself. I guess
there are not many.

> 2. What exactly is the role of the root object,
>     traditionally created as ``root=tk.Tk()``?
>     What is an example where one should create this
>     before creating a Frame instance (which will
>     otherwise implicitly create one as its master)?

The object traditionally called root is in fact an instance of the tcl
interpreter that will get the commands generated by the Tkinter module. Due to
tk architecture, creating this interpreter will also create a window, which is
inteneded to be your application's main window. This window is called '.' in
tcl/tk. The root object in Tkinter then represents this '.' window. So the
instance of Tk is actually 2 things:
- The interpreter itself;
- The main window for your application.

As for when you should create explicitely an instance of Tk, well, I'd say
always ;-) Creating an instance of Frame without creating a Tk instance first
will actually create one, but you'll have no direct access to it. And you
might want an access to it for quite a number of reasons: hiding it, make it
an icon, add menus to it, and so on... All these operations can be done on
actual windows, not on a Frame which is just a container widget.

> 2. Suppose I ``import tkinter as tk`` and
>     then try ``s1=tk.StringVar()``.  This fails
>     because no "master" is set. Why does a
>     Variable need a master?

Because it needs a tcl interpreter to be created. All Tkinter widget actually
reference their interpreter in their tk attribute. The StringVar will probably
just use that.

> 3. Now suppose I set ``root = tk.TK()`` and
>     then try ``s1=tk.StringVar()``.  This
>     works fine but now seems a bit magical:
>     how has the value of the "master" been
>     set?

The Tk instance is registered in a hidden variable in the Tkinter module. When
you don't specify a master, it'll use the latest created Tk instance one by
default. BTW, the latest should be the only one: it is quite unsafe to create
several Tk instances in the same application.

> 4. Another bit of magic:
>     Suppose I ``import tkinter as tk`` and
>     then try ``f1=tk.Frame()``.  This works
>     fine: apparently calling Frame also
>     leads to implicit creation of a "master".
>     Why is what is good for the gander (i.e.,
>     implicit master creation for a Frame) not
>     good for the goose (i.e., a Variable)?
>     (Here I assume that there has been an
>     answer to 2. above.)

Well, I personnally don't see any point on doing any master creation
implicitely, so I never use this master auto-creation for anything. I guess
that having a window automatically created when you just try to instantiate a
variable has been considered weird. But it's just a guess...

> 5. Reading around a bit,
>     it seems common to recommend setting
>     the values of Variables rather than initializing
>     them.  Why?  I cannot see the reason to avoid
>     ``s1=tk.StringVar(value="this works fine")``
>     and it looks like ``tk.StringVar(()`` is in any
>     case initialized (to an empty string).

I've never seen such a recommendation anywhere. I do tend to rely on the
variable's default values.

> 6. Why is str(s1) not its value?  More generally,
>     why does a StringVar not behave more like a string?

Well, that's a question for the guys who made the Tkinter module. My guess
would be that StringVar's are supposed to be used only to communicate between
the Python layer and the tcl one. They are not intended to be used as actual
strings in your application. Don't forget anything you do on a StringVar is
actually done by tcl, not Python. So I guess there is also a performance
penalty to use StringVar's instead of Python strings.

> Thanks for any insights,
> Alan Isaac

HTH
 - Eric -



More information about the Python-list mailing list