How to choose the right GUI toolkit ?

[Dan Lenski]

Hi all,
I'm a recent, belated convert from Perl. I work in a physics lab and
have been using Python to automate a lot of measurement equipment
lately. It works fabulously for this purpose. Recently I've wanted to
start writing GUIs for some of my programs, for data visualization and
to make the programs easier to use for some of my co-workers.

So far I've experimented with two Python GUI toolkits: Tkinter and
PyGTK. I've had some issues with each:

* PyGTK - not very "pythonic", in my opinion. Have to use get_ and
set_ methods rather than properties. Have to write ugly things like
textview.insert(textview.get_end_iter(), ...) to append text to a text
buffer. No useful doc strings, which makes experimenting with new
widgets in IPython a huge pain. The toolkit feels very "heavyweight".
I don't want to write an XML file and an "action group" just to make a
piddly little menubar with 10 items.

I'm an avid Gnome fan, and love the professionalness and completeness
of GTK, but PyGTK seems frustratingly C-like compared to the
wonderfully designed high-level abstractions I've come to love in
Python!

* TkInter - Seems easy to learn, and better for quick "lightweight"
GUIs. I wrote a complete working instrument GUI in less than a day of
figuring things out. Not very Pythonic in terms of creating and
modifying widgets. No factory functions to quickly create menu items.
My biggest problem with Tkinter is that it is very unreliable under
Cygwin: programs freeze and slow intermittently and the tkMessageDialog
stock dialog boxes show no visible text.

So, is there another toolkit I should be looking at? Having something
that can run easily on Cygwin and native Windows is a priority so that
I can quickly move programs to new measurement computers. I like GTK a
lot and Tk is growing on me too.. are there any higher-level "wrapper"
toolkits for GTK and Tk?

Thanks for any advice!

Dan Lenski
University of Maryland

 

[John Salerno]

So, is there another toolkit I should be looking at?

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.

http://www.wxpython.org/

 

[John Henry]

I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well. I can't really compare it to
other toolkits (not having used any of them, except Tkinter), but it's
definitely one of the most popular and well-supported ones out there.

http://www.wxpython.org/

I highly recommend that you try PythonCard (which sits on top of
wxPython). You can get productive very very quickly. Take a look at:

http://pythoncard.sourceforge.net/walkthrough1.html

 

[Nick Craig-Wood]

I highly recommend wxPython.

I'd second that!

There is a book also

"WxPython in Action"

http://www.amazon.com/Wxpython-Action-Noel-Rappin/dp/1932394621

Which is certainly my preferred way of learning new stuff!

It's very mature, full-featured, and portable, and fairly easy to
learn as well.

....with native look and feel on each platform unlike GTK / TK

It has got a huge set of widgets and an excellent demo program in
which you can try them all out and steal their code.

There are some bits of it in which the C++ heritage sticks out, but
over the years the toolkit designers have been tucking those under the
carpet. The MethodNaming is a bit odd too!

A minor annoyance is that there are a number of features which only
work on a subset of the platforms. These are well documented though.

IMHO the best of the toolkits, but it is a personal choice and yours
may differ!

There is also PyQT which we wrote off as we wanted to write commercial
applications too. As it happens we have a commercial QT licence, but
we decided we didn't want to have to incurr the additional expense of
renewing it.

 

[Christophe]

Nick Craig-Wood a écrit :

There is also PyQT which we wrote off as we wanted to write commercial
applications too. As it happens we have a commercial QT licence, but
we decided we didn't want to have to incurr the additional expense of
renewing it.

Note: Nothing in the GPL prevents you from writting commecial software

 

[Nick Craig-Wood]

Nick Craig-Wood a écrit :
Note: Nothing in the GPL prevents you from writting commecial
software

A completely valid point!

s/commercial applications/closed source applications/ would be more
accurate.

However, in this case, our customer didn't want the source code
released as it contained some of their confidential stuff.

 

[John Salerno]

I'd second that!

There is a book also

"WxPython in Action"

Oh yeah, how could I forget "The Book"! It's great to read straight
through, and also a fantastic reference, and covers just about all there
is to know to get very far in wxPython.

 

[Michael Hobbs]

Can anyone find a flaw with this change in syntax?

Instead of dividing a compound statement with a colon, why not divide it
on a newline? For example, the colon could be dropped from this statement:
if self.hungry:
self.eat()
to
if self.hungry
self.eat()

Python is already sensitive to whitespace and the newline anyway, so why
not put it to good use? For example, Python rejects this statement
because of the newline present:
if self.hungry or
self.depressed:
self.eat()
You need to use the backslash to continue the expression on the next line:
if self.hungry or \
self.depressed:
self.eat()
The colon that divides the statement therefore seems redundant. The
colon could continue to be used for single-line statements:
if self.hungry: self.eat()

I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything?

Thanks,
- Mike

 

[Paul Boddie]

I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything?

The FAQ answer. ;-)

http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

Paul

 

[Marc 'BlackJack' Rintsch]

Python is already sensitive to whitespace and the newline anyway, so why
not put it to good use? For example, Python rejects this statement
because of the newline present:
if self.hungry or
self.depressed:
self.eat()
You need to use the backslash to continue the expression on the next line:
if self.hungry or \
self.depressed:
self.eat()

You don't need the backslash if you use parenthesis:

if (self.hungry
or self.depressed):
self.eat()

I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing anything?

I would miss auto-indenting in my editor to which the colon at the line
end is an important clue.

Ciao,
Marc 'BlackJack' Rintsch

 

[Michael Hobbs]

The FAQ answer. ;-)

http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

Paul

I knew there was a document somewhere that I missed. ;-) I even scanned
all the Py3K PEPs before posting. Anyway, the FAQ answer seems to be a
weak argument to me. But if the BDFL insists that it remains, why not
take the converse approach? That is, assume that the expression ends at
the colon, not at the newline. That would make this type of statement
possible:
if color == red or
color == blue or
color == green:
return 'primary'
Right now, such a statement would have to be spelled thus:
if color == red or \
color == blue or \
color == green:
return 'primary'
or
if (color == red or
color == blue or
color == green):
return 'primary'

 

[Steve Holden]

The FAQ answer. ;-)

http://www.python.org/doc/faq/general/#why-are-colons-required-for-the-if-while-def-class-statements

Paul

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

regards
Steve

 

[Dan Lenski]

I'd second that!

There is a book also

"WxPython in Action"

Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows. I too like to learn from
actual printed books, so I'll check this one out. O'Reilly should do a
book on Python GUI stuff!

John H.: thanks for pointing out pythoncard. This looks like it might
be an excellent substitute for LabView-like GUIs, which all my
coworkers like. I personally refuse to read or write LabView code, on
the grounds that its syntax causes severe brain damage and is
completely unportable. But that's a flame for another thread, so to
speak...

Thanks,
Dan

 

[Paul Boddie]

I suppose it would be even better if that hyperlink actually took you to
section 1.4.27 rather than 1.4.14 ...

I'd suggest a browser upgrade: even the old version of Konqueror I'm
using here manages to scroll to the right place. And it isn't a Web
site maintenance problem, either, although I did have my suspicions.

Paul

 

[Christophe]

Dan Lenski a écrit :

Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows.

Qt is very well supported under Windows! Avoid spreading lies please


( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

 

[Jeremy Sanders]

Nick and John S., thank you for the tip on wxPython! I'll look into it
for my next project. I too would avoid Qt, not because of the GPL but
simply because I don't use KDE under Linux and because Qt is not well
supported under Cygwin or on native Windows. I too like to learn from
actual printed books, so I'll check this one out. O'Reilly should do a
book on Python GUI stuff!

PyQt is well supported under native Windows. Qt-4 is now GPLd for Windows
too. I'd highly recommend it.

Jeremy

 

[Daniel Dittmar]

But if the BDFL insists that it remains, why not
take the converse approach? That is, assume that the expression ends at
the colon, not at the newline. That would make this type of statement
possible:

I suggested something like this a while back. The answer then was that
error messages in case of a forgotten colon would be misleading, at the
wrong position, or both.

Today:

if a or b
print x

File "colontest.py", line 2
if a or b
^
SyntaxError: invalid syntax

Daniel

 

[Steve Holden]

I'd suggest a browser upgrade: even the old version of Konqueror I'm
using here manages to scroll to the right place. And it isn't a Web
site maintenance problem, either, although I did have my suspicions.

YTes, IE copes with it but Firefox doesn't. Having heard a number of
complaints about Firefox 2 I'm tempted to stick with 1.5.0.8 just a
little longer.

regards
Steve

 

[Dan Lenski]

Dan Lenski a écrit :
Qt is very well supported under Windows! Avoid spreading lies please

My apologies! I'm glad to be corrected on this. There are Cygwin
packages for Qt as well, but I have heard about enough bugs to think I
should avoid Qt. I have used enough Gtk apps that run flawlessly under
Windows to have my hopes that it works well.

( and I must admit one of the reasons I avoid wx if possible, is because
I don't use Gnome under Linux and the look and feel of wx applications
is really horrible under KDE )

My understanding is that wx wraps Windows, OSX, Qt, and GTK+... I guess
some of the wrappers fit the native apps better than others?

Dan

 

[Wojciech =?iso-8859-2?Q?Mu=B3a?=]

...with native look and feel on each platform unlike GTK / TK

AFAIK Tk 8 uses platform's native widgets.

w.