[Tutor] Is it a good idea to use TKInter to change my password program into a GUI?

[Danny Yoo]

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:

Hi Nathan,

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

> 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
login info:

######
def ask_for_login_info():
    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
list:

######
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".

  http://www.pythonware.com/library/tkinter/introduction/dialog-windows.htm

On a first pass to GUI-ify your program, each 'print' statement could be
replaced with something like a printDialogMessage():

######
import tkSimpleDialog
import Tkinter

def printDialogMessage(root, msg):
    """Uses a dialog window to display a message.  If ok is pressed,
    returns True.  If cancel is pressed, returns False.
    """
    class Dialog(tkSimpleDialog.Dialog):
        def body(self, master):
            Tkinter.Label(master, text=msg).pack()
        def apply(self):
            self.result = True
    d = Dialog(root)
    if d.result:
        return True
    return False
######

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:

   http://www.manning.com/books/grayson

helpful in getting started with Tkinter programming.


Hope this helps!