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_e nd_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 "heavyweigh t".
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 professionalnes s 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 "lightweigh t"
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]

Dan Lenski wrote:

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]

John Salerno wrote:

Dan Lenski wrote:

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/

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]

John Salerno <jo******@NOSPA Mgmail.comwrote :

Dan Lenski wrote:

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

I highly recommend wxPython.

I'd second that!

There is a book also

"WxPython in Action"

http://www.amazon.com/Wxpython-Actio.../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.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[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]

Christophe <ch************ *@free.frwrote:

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 ;)

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.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[John Salerno]

Nick Craig-Wood wrote:

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

I highly recommend wxPython.

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]

Michael Hobbs wrote:

>
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/genera...ass-statements

Paul

[Marc 'BlackJack' Rintsch]

In <ma************ *************** ************@py thon.org>, Michael Hobbs
wrote:

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