Programming Python (62 page)

Example 8-30. PP4E\Gui\Tour\demoScale.py

"create two linked scales used to launch dialog demos"
from tkinter import *                # get base widget set
from dialogTable import demos        # button callback handlers
from quitter import Quitter          # attach a quit frame to me
class Demo(Frame):
def __init__(self, parent=None, **options):
Frame.__init__(self, parent, **options)
self.pack()
Label(self, text="Scale demos").pack()
self.var = IntVar()
Scale(self, label='Pick demo number',
command=self.onMove,                   # catch moves
variable=self.var,                     # reflects position
from_=0, to=len(demos)-1).pack()
Scale(self, label='Pick demo number',
command=self.onMove,                   # catch moves
variable=self.var,                     # reflects position
from_=0, to=len(demos)-1,
length=200, tickinterval=1,
showvalue=YES, orient='horizontal').pack()
Quitter(self).pack(side=RIGHT)
Button(self, text="Run demo", command=self.onRun).pack(side=LEFT)
Button(self, text="State",    command=self.report).pack(side=RIGHT)
def onMove(self, value):
print('in onMove', value)
def onRun(self):
pos = self.var.get()
print('You picked', pos)
demo = list(demos.values())[pos]    # map from position to value (3.X view)
print(demo())                       # or demos[ list(demos.keys())[pos] ]()
def report(self):
print(self.var.get())
if __name__ == '__main__':
print(list(demos.keys()))
Demo().mainloop()

• The
  label
option
  provides text that appears along with the scale,
  length
specifies an initial size
  in pixels, and
  orient
specifies
  an axis.
  

• The
  from_
and
  to
options
  set the scale range’s minimum and maximum values (note
  that
  from
is a Python reserved
  word, but
  from_
is not).
  

• The
  tickinterval
option
  sets the number of units between marks drawn at
  regular intervals next to the scale (the default means no marks are
  drawn).
  

• The
  resolution
option
  provides the number of units that the scale’s value
  jumps on each drag or left mouse click event (defaults to 1).
  

• The
  showvalue
option
  can be used to show or hide the scale’s current value
  next to its slider bar (the default
  showvalue=YES
means it is drawn).
  

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:\...\PP4E\Gui\Tour>
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.

Example 8-32. PP4E\Gui\Tour\demoAll-frm.py

"""
4 demo class components (subframes) on one window;
there are 5 Quitter buttons on this one window too, and each kills entire gui;
GUIs can be reused as frames in container, independent windows, or processes;
"""
from tkinter import *
from quitter import Quitter
demoModules = ['demoDlg', 'demoCheck', 'demoRadio', 'demoScale']
parts = []
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
parts.append(part)                              # change list in-place
def dumpState():
for part in parts:                                  # run demo report if any
print(part.__module__ + ':', end=' ')
if hasattr(part, 'report'):
part.report()
else:
print('none')
root = Tk()                                             # make explicit root first
root.title('Frames')
Label(root, text='Multiple Frame demo', bg='white').pack()
Button(root, text='States', command=dumpState).pack(fill=X)
Quitter(root).pack(fill=X)
addComponents(root)
root.mainloop()

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.

Example 8-33. PP4E\Gui\Tour\demoAll-win.py

"""
4 demo classes in independent top-level windows;
not processes: when one is quit all others go away, because all windows run in
the same process here; make Tk() first here, else we get blank default window
"""
from tkinter import *
demoModules = ['demoDlg', 'demoRadio', 'demoCheck', 'demoScale']
def makePopups(modnames):
demoObjects = []
for modname in modnames:
module = __import__(modname)          # import by name string
window = Toplevel()                   # make a new window
demo   = module.Demo(window)          # parent is the new window
window.title(module.__name__)
demoObjects.append(demo)
return demoObjects
def allstates(demoObjects):
for obj in demoObjects:
if hasattr(obj, 'report'):
print(obj.__module__, end=' ')
obj.report()
root = Tk()                                   # make explicit root first
root.title('Popups')
demos = makePopups(demoModules)
Label(root, text='Multiple Toplevel window demo', bg='white').pack()
Button(root, text='States', command=lambda: allstates(demos)).pack(fill=X)
root.mainloop()