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

[Ron Adam]

Steve Holden wrote:

I'm always surprised by the amount of energy that's put into this type
of discussion - even the OP has suggested that this isn't a big issue.
If it's not a big issue why is this thread still going? Every language
has a syntax. Why not just accept it as a given and get on with more
productive activities?

It's because it's not an issue with an obviously (clear to everyone) good or bad
answer.

Obvious bad answer - short discussion

Obvious good answer - short discussion which spawns many long discussion
about the not so obviously details.

* Nearly a toss up -really long discussion that rehashes things over and
over from various micro points of view.

Even though it's pretty much known this won't change, people still want the
clarity of an obvious answer even if an obvious solution doe not exist, so the
thread continues. And of course what is obvious or not isn't obvious to
everyone, so that too is a long discussion. ;-)

But I think this thread has a second underlying attribute that appeals to the
participants. It isn't so much an effort to change anything as it is an effort
to explore and understand why things where made the way they are. To those who
already know, this seems silly, but to those who are still learning, it seems
important.

This could be broken down a bit more, but then we would get into long debates on
the best non-obvious ways to do that. ;-)

Cheers,
Ron

[Hendrik van Rooyen]

"Fredrik Lundh" <fr*****@python ware.comwrote:

have anyone counted the number of colons used in this way by the OP,
in his first few posts ? (if there isn't a name for the law that
states that the number for a "let's remove the colons" proposal is
always greater than zero, someone should come up with one...)

You just have - how do you want it to be immortalised?

The effbot's law of colonic inevitability?

- Badger (for Steve)