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

[Michael Hobbs]

Paul Boddie wrote:

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

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]

Paul Boddie wrote:

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

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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Dan Lenski]

Nick Craig-Wood wrote:

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"

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]

Steve Holden wrote:

Paul Boddie wrote:

http://www.python.org/doc/faq/genera...ass-statements

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]

Dan Lenski wrote:

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

--
Jeremy Sanders
http://www.jeremysanders.net/

[Daniel Dittmar]

Michael Hobbs wrote:

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]

Paul Boddie wrote:

Steve Holden wrote:

>Paul Boddie wrote:

>>http://www.python.org/doc/faq/genera...ass-statements

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.

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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

[Dan Lenski]

Christophe wrote:

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

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 Mu³a]

Nick Craig-Wood wrote:

> 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

AFAIK Tk 8 uses platform's native widgets.

w.