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

Dan Lenski wrote:

>
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

I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

[John Salerno]

Michael Hobbs wrote:

Anyway, the FAQ answer seems to be a
weak argument to me.

I agree. I was expecting something more technical to justify the colon,
not just that it looks better.

[Dan Lenski]

John Henry wrote:

I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

That's right, I'm saying the GUIs *produced* by PythonCard look like
those produced by LabView. Believe me, if the PythonCard programming
style had anything to do with LabView, I'd avoid it like the plague =)

In any case, I think I'm gonna give PythonCard a shot before trying
full-fledged wxPython. It looks ideal for my needs.

Dan

[Neil Cerutti]

On 2006-11-09, John Salerno <jo******@NOSPA Mgmail.comwrote :

Michael Hobbs wrote:

>Anyway, the FAQ answer seems to be a weak argument to me.

I agree. I was expecting something more technical to justify
the colon, not just that it looks better.

I think it is outstanding that the colon's justification is
asthetic rather than technical (though I too had expected to see
a technical excuse for it).

--
Neil Cerutti

[Tim Chase]

>>Anyway, the FAQ answer seems to be a weak argument to me.

>I agree. I was expecting something more technical to justify
the colon, not just that it looks better.

I think it is outstanding that the colon's justification is
asthetic rather than technical (though I too had expected to see
a technical excuse for it).

Though by such justifications based on asthetics, the interpreter
should also enforce that class-names begin with capital letters,
that camel-case is eschewed in favor of underscore_sepa ration.
And perhaps enforce a 79-column character limit on text. Perhaps
also put a cap on the number of punctuation characters on a given
line as well to prevent the code from looking too much like
Perl... ;*)

A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)

Shaving-with-Occam's-disposable-razor'ly yers...

-tkc

[sjdevnull]

Steve Holden wrote:

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.

FWIW, Firefox 2.0 and 1.5.0.7 both work properly on this link (as does
Epiphany 1.2.10). Linux 2.6-based system.

[Steve Holden]

Dan Lenski wrote:

John Henry wrote:

>I assume you meant that the example programs looks LabView-like GUIs?
PythonCard itself has nothing in common with LabView. It's more like
HyperCard.

That's right, I'm saying the GUIs *produced* by PythonCard look like
those produced by LabView. Believe me, if the PythonCard programming
style had anything to do with LabView, I'd avoid it like the plague =)

In any case, I think I'm gonna give PythonCard a shot before trying
full-fledged wxPython. It looks ideal for my needs.

You may find that it starts out fine, but becomes less satisfactory as
the sophistication of your interfaces increases. Then the problem will
be that migration to another platform demands a substantial rewrite of
your application (I have done this for a fairly small app).

I don't think PythonCard gets much maintenance nowadays.

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]

Wojciech Mula wrote:

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.

Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP. But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop. Is there a way to get it to do so?

Dan

[Bjoern Schliessmann]

Dan Lenski wrote:

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.

Why not?

BTW, big projects such as the Opera browser use Qt. Also in Windows.

Regards,
Björn

--
BOFH excuse #381:

Robotic tape changer mistook operator's tie for a backup tape.

[Bjoern Schliessmann]

Michael Hobbs wrote:

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'

What about

if color == red or blue or green:
return 'primary'

:)

Really, I think it'd be more mess to let the if statement's end only
depend on ":". I think there could arise situations that are messy
to debug. If I need multiple lines I prefer the parentheses.

Regards,
Björn

--
BOFH excuse #295:

The Token fell out of the ring. Call us when you find it.