Re: RE: [Tutor] On GUI's
magnus at thinkware.se
Wed Apr 21 15:55:19 EDT 2004
I assume this was for the list too:
> >From what you've described, it seems like you've taken the gui as the
> program. From what I've read from tkinter manuals and such, gui's seem
> more like a front end to functions. I don't know if this is just a
> fault of perception on my part or not, or if there is really any
> difference at all.
A GUI is certainly a front end to a computer program, but in many
cases, the application logic is very tightly coupled with the GUI.
You can do things differently. Tkinter is a wrapper over Tk, which is a
GUI toolkit for the Tcl scripting language. Tcl is mainly intended as a
"glue" language, a tool to provide a thin GUI and/or automation layer
over other programs developed in systems programming languages such as
C, C++ or Fortran.
Regardless of your programming language and GUI tool kit, it's usually
a good idea to try to make your GUI code thin and separate from the
application logic, but this is something that needs to be determined
individually for each project.
Python is not the kind of simple scripting language Tcl is. It's very
capable of handling advanced application logic, but it's still a good
idea to keep logic and GUI in separate modules.
The reason I described a non-GUI solution to an everyday problem was
mainly to try to make people think outside the box. Most people have
become so used to GUIs that they take them for granted and expect them
to be the normal interface with the computer. This is a bit sad, since
the GUI is often a dead end.
> In the example you give, if I were to consider a gui for this sort of
> app, I would want to just have a set of buttons that just run the
> various command lines (rather, the functions that the command lines
> effectively run with those args) maybe having some sort of display
> window to show the results. Could this be as effective? Or am I
> looking at this all wrong? Are there any 'rules of thumb' when it comes
> to creating gui's?
The Unix Philosophy suggests that you should write every program as a
filter, make each program do one (and only one) thing well, and to use
pipes and files to combine differnent programs to provide a multitude
This is a very powerful approach, but it has two shortcomings:
- It assumes quite a bit of skill from each computer user.
- A stream of text sent from stdout of one program to stdin
of the next isn't always the best data structure for data
exchange between two pieces of code.
As you are suggesting, python modules importing and calling each other
opens for more power with less effort than the traditional Unix approach.
And in Python it's easy to make a program file work both as a module
to be used by others, and as a stand alone program.
The Unix approach is still vastly superior to the traditional Windows
approach to computer use though, where people often do things like
run a monolithis program which displays a result in a window, and then
they open another monolithic application and manually type what they see
in the first window into a text entry field in the second window. Yuk!
(Fortunately, Python and cygwin comes to the rescue for us who have to
use Windows. After all, even Mac OS is Unix these days, and comes bundled
with Python, so it's good that those crippled systems from Redmond can
be complemented with some proper stuff! ;)
For program integration approaches that allows you to use Python with
code written in other languages, see
Anyway, I hope that even in this day and age, people will not always
take a GUI for granted for every program they write, but that they
consider other approaches to data entray, and most importantly, that
they consider how useful it is to be able to quickly integrate
various components into a new function.
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus at thinkware.se
More information about the Tutor