[Tutor] Is it a good idea to use TKInter to change my password program into a GUI?
falcon3166 at hotmail.com
Tue Nov 29 21:48:21 CET 2005
Hey Danny and all,
Alberto told me that there was a password entry box in TKInter. Can anyone
tell me about that, please?
Owner/operator of The Web Surfer's Store.
MSN Messenger: falcon3166 at hotmail.com
Yahoo! Messenger: spam_swatter31
From: Danny Yoo [mailto:dyoo at hkn.eecs.berkeley.edu]
Sent: November 28, 2005 2:57 PM
To: Nathan Pinno
Cc: Albertito Troiano; Tutor Mailing List
Subject: Re: [Tutor] Is it a good idea to use TKInter to change my password
program into a GUI?
On Sun, 27 Nov 2005, Nathan Pinno wrote:
> Is it a good idea to use TKInter to change my password program into a
> GUI? I know it needs improvements, and I've noted them below:
Yes, some of it should be usable if it were in a GUI. The easy way to pick
out what functions will and won't be useful is this: what functions use
print and input statements? If you exclude those, then what's left will be
useful for both your GUI and terminal programs.
Actually, that's not quite accurate. For functions that do use print
statements, it's possible to split off the console-driven stuff from the
pure computation stuff, so there's actualy quite a bit you can reuse.
Let's go into this.
load_file() and safe_file() are directly reusable, since they don't interact
with the user. Let's look at something that mixes computation with user
> def add_site():
> print "Add a login info card"
> site = raw_input("Site: ")
> ID = raw_input("User ID and passcard, seperated by a space: ")
> sitelist[site] = ID
It's possible to break this down into two parts: the part that asks for
print "Add a login info card"
site = raw_input("Site: ")
ID = raw_input("User ID and passcard, seperated by a space: ")
return (site, ID)
and the part that really does the gruntwork of entering into the site
def add_to_sitelist(site, ID):
sitelist[site] = ID
Because this example is so small, doing the breakup this way is a bit silly,
so maybe this is overkill for your program. But, in general, when we design
a program to be used from both the console and the GUI, we'd break out the
direct user interface stuff into a separate set of "user interface"
functions, and have those interface functions reuse the common "model"
functions that do the underlying work.
In a GUI framework like Tkinter, the ask_for_login_info() function might use
a "dialog box".
On a first pass to GUI-ify your program, each 'print' statement could be
replaced with something like a printDialogMessage():
def printDialogMessage(root, msg):
"""Uses a dialog window to display a message. If ok is pressed,
returns True. If cancel is pressed, returns False.
def body(self, master):
self.result = True
d = Dialog(root)
Similarly, we can write something (let's call it readDialogInput) that
simulates the console raw_input() function. And if you replace each use of
'print' with 'printDialogBox' and 'raw_input' with 'readDialogInput', we
could argue that we have a GUI program.
But if we take this route and just stop here, then this is no better than
the console program. Getting GUIs right is more than just taking existing
programs and putting nice shiny windows on them: it involves good user
interface design that takes advantage of the things that GUIs get right.
I don't know if there's a quick-and-dirty way to design such GUIs, though.
You might find:
helpful in getting started with Tkinter programming.
Hope this helps!
More information about the Tutor