[Tutor] Learn as You Go. Tkinter, PIL, Pmw, etc. and Toolkits--Choices

Alan Gauld alan.gauld at btinternet.com
Sun Apr 5 10:26:31 CEST 2009


"Wayne Watson" <sierra_mtnview at sbcglobal.net> wrote

>  I get the feeling, particularly with Tkinter and PIL, that I'm dealing
> with antiquated  tools, and documentation.

They are both quite old and therefore quite stable. They do what
they do well and don't need to change very often. That is a
Good Thing in that they are reliable and well understood in
the community. I'd much prefer to use software that has a large
installed base and hasn't changed in the last year or so than
something that is still in active development and only at
version 0.9 or whatever. (Althougfh I'd still prefer the latter to
writing it myself! :-)

> I inquired about Pmw here, and it too looks a little old.

It is old and with very little activity. It was never mainstream.

> I recently bought the book Core Python and decided to look
> at his section on toolkits. I see Pmw was meant as a
> replacement for Tkinter.

No PMW builds on top of TKinter in the same way as Tix does.
It addresses weaknesses in the size of the widget set that
Tk supports (remember Tkinter - and most Python toolkits - is
just a wrapper around another toolkit in another langage, in
this case Tk.)

> After my grid experience, I hope so.

The grid is a perfectly good layout manager but like all such
tools it works in a particular way and has lots of options. Some
things are better done with the packer or placer (and the new form)
managers. The designer has to pick the best tool for the job.

> Probably grid is pretty sound, but the documentation I've dug up
> doesn't seem sufficient.

The Python documentation for Tkinter generally is quite good to
get you started but there is a real lack of in depth stuff. For that
you really need to go to the Tk sources. Fortunately translating
Tk to Tkinter is pretty easy. Even better the new Tk web site is
starting to give example code for Perl and Ruby as well as Tk
so it is even easier to see how it works in other languages.

> Perhaps grid is still a foundation in Pmw.

Yes, PMW builds out of Tkinter it not separate.

But I suspect that with Tix now in the standard library and
doing most of what PMW does that PMW will tend to wither
and die. If someone produced a really good reference for
Tkinter and Tix (especially based on the new Tk widget set)
then things would be a whole lot better in Python GUI land.

> My view is that it could be better described.

Totally agree, although the Tk docs are more comprehensive.
(Although oddly not so good for beginners!)

> the author briefly describes wxWidgets.

This is a completely separate GUI framework which is more
comprehensive than Tkinter, even with PMW or Tix. But its
a whole new learning curve and is not standard Python Library.

> Tix,

The now official extension library to Tkinter, given extra widgets.

> GtK+, PyGTK,

Python wrapper around yet another set of GUI widgets.
I've never used it so can't comment. Some people like it.
If you use it in another language then its the obvious choice.

> FXpy,

Never even heard of this one!

> PyOpenGL.

This is a wrapper around the OpenGL graphics library,
closer to PIL in function than to Tkinter. Its all about drawing
to screen quickly. If you need dynamic screen gtraphics you
may need this.

> They probably all have a place,

Just so. Each does a specific job, or wraps a specific external
toolkit to look at least a bit like Python.

> If I had to guess, I might think Pmw might be a good choice to
> carry the ball into graphics.

Nope, it doesn't offer much for graphics, its really a set of widgets
(a spreadsheet like table, combo boxes etc) and a framework for
building other widgets. But it is not graphics oriented particularly.

> I base that on looking at the chapter 10 contents I posted a few weeks 
> ago.

Remember Grayson is about 10 years old now so there are newer
tools. But most of Chapter 10 is based on the Canvas widget which
is pure Tkinter and the baseline tool for drawing graphics in Tk.

If you are drawing graphs for example there are other libraries
that work with Tkinter that will be much easier than using the canvas.

> So here I am wondering if instead of Tkinter or Python, maybe I
> should take up Pmw or some other toolkits.

Most of the ther toolkits will have similar issues. Even wxPython
which is the Python wrapper around wxWidgets, requires you to
read the C++ documentation and code from time to time. This is
always going to happen when you build a wrapper around another
language toolkit. PMW is built onTkinter which is built on Tk which
is built on C!.

> Given the sparseness of the PIL documents, I may end up doing
> a lot of needless experimenting that is available some other way.

I've only used PIL in very basic work. But it is your best option for
graphics manipulation in Python I suspect. Displaying the images
created will require interaction with the GUI and PIL does at least
work with Tkinter...

But experimenting interactively is core to building software in any
environment. Most of these toolkits have so many options that its
virtually impossible to document every possible interaction of every
option. You must experiment to see how the bits you are interested
in will work together. It's what software engineers do... As I say in
the concepts section oof my tutorial:

-------------------------------
The other thing that is useful is the right mind set to program.
What I mean by that is an innate curiosity about things, coupled to
a logical way of thinking. These are both essential requirements
for a successful programmer.

The curiosity factor comes into play in looking for answers to
problems and being willing to dig around in sometimes obscure
documents for ideas and information needed to complete a task.

The logical thinking comes into play because computers are
intrinsically stupid. They can't really do anything except add single
digits together and move bytes from one place to another. Luckily for
us some talented programmers have written lots of programs to
hide this basic stupidity. But of course as a programmer you may
well get into a new situation where you have to face that stupidity
in its raw state. At that point you have to think for the computer.
You have to figure out exactly what needs to be done to your data
and when.
------------------------------------------

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/l 




More information about the Tutor mailing list