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

[Fredrik Lundh]

Antoon Pardon wrote:

Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

so why are you still here?

</F>

[Antoon Pardon]

On 2006-11-14, Fredrik Lundh <fr*****@python ware.comwrote:

Antoon Pardon wrote:

>Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

so why are you still here?

Because I have a different opinion and I don't need your permission.

--
Antoon Pardon

[Dan Lenski]

Hendrik van Rooyen wrote:

This is true - and it is actually also an intractable problem - if you look at
what your daughter wrote, you get the feeling that you should be able to write
an interpreter that can implement what she meant, because it is quite clear to
you - until you try to write the specs...

Unfortunately natural language is completely riddled with ambiguities
about negation and conjunction. It doesn't seem like a good idea for
programming languages to emulate these too closely, even if it does
make for more "natural" constructions.

For example:
"You must not go there." means "You are forbidden to go there."
"You do not have to go there." means "You are not required to go
there."
Similar negations of two English verbs with virtually identical meaning
makes quite a difference in the semantics of the complete sentence!

Likewise, double negation is perfectly equivalent to single negation in
many languages, including in some dialects of English:
"I ain't got time." means "I don't have time."
"I ain't got no time." means "I don't have time."

Another problem is that the English word "or" sometimes means
"inclusive or" and sometimes means "exclusive or":
"Do you have any brothers or sisters?" (inclusive or)
"You can carry on a briefcase or a backpack." (exclusive or)

I think part of learning to think like a computer is learning to stop
associating computer logic too strongly with the natural language
meanings of "and", "or", and "not".

Dan

[Robert Kern]

Hendrik van Rooyen wrote:

"Robert Kern" <ro*********@gm ail.comwrote:

>Michael Hobbs wrote:

>>True enough. Although, I have to ask how many times you define a new
function only to have Python spit a syntax error out at you saying that
you forgot a colon. It happens to me all the time. (Usually after an
"else") If you'd never notice that the colon was missing if the compiler
didn't point it out, is it really that readable? For me, I tend to get
annoyed at language "features" that I'm constantly tripping over.

Never.

I confess I find myself in the position of a Yorkshire Youngster - I don't
believe you!

Okay, not often enough or annoyingly enough for me to remember having done so.
Perhaps seven years ago when I started using Python, but not any time recent.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[skip]

>>Michael Hobbs wrote:

>>>True enough. Although, I have to ask how many times you define a new
function only to have Python spit a syntax error out at you saying that
you forgot a colon. It happens to me all the time.

I confess I find myself in the position of a Yorkshire Youngster - I
don't believe you!

RobertOkay, not often enough or annoyingly enough for me to remember
Roberthaving done so. Perhaps seven years ago when I started using
RobertPython, but not any time recent.

If your editor knows about Python's block structure (as Emacs's python-mode
does), when you forget the colon it's immediately obvious because the next
line doesn't autoindent properly.

Skip

[Terry Reedy]

<sk**@pobox.com wrote in message
news:17******** **************@ montanaro.dyndn s.org...

>I confess I find myself in the position of a Yorkshire Youngster -

I

>don't believe you!

RobertOkay, not often enough or annoyingly enough for me to remember
Roberthaving done so. Perhaps seven years ago when I started using
RobertPython, but not any time recent.

If your editor knows about Python's block structure (as Emacs's
python-mode
does), when you forget the colon it's immediately obvious because the
next
line doesn't autoindent properly.

The same is true of the editor in IDLE.

[Stephen Eilert]

Carl Banks escreveu:

Steve Holden wrote:

In fact most Python doesn't use such constructs, though I'll admit the
occasional __init__ is more or less inevitable once you start using the
object-oriented features more than casually.

Occasional? I don't know about you, but I use __init__ in 99% of the
classes I define. :) I don't think __special_symbo ls__ are manifestly
unsuitable for newbies--they're just special.

I was curious how much I used these symbols. For my current largish
project:

306 __init__
68 __future__
44 __dict__
3 __name__
3 __main__
3 __import__
3 __builtin__
2 __str__
2 __file__
1 __setitem__
1 __setattr__
1 __repr__
1 __or__
1 __ne__
1 __int__
1 __getitem__
1 __getattribute_ _
1 __eq__
1 __call__
1 __add__

Excepting my use of __dict__, not a whole lot advanced usage there, and
I am NOT the kind of person who's afraid to do advanced things when
it's useful. Much of the advanced stuff, including __dict__, is for
debugging. (I have a lot of classes that acquire resources that I must
explicity release, so I clear the __dict__ to catch any post-release
accesses, which could cause subtle failures otherwise.)
Carl Banks

Well, I *hate* underscores with a passion. So it is kinda frustrating
that I *have* to say "__init__". The fact that the coding conventions
for Python suggest things such as methods_called_ this_or_that do not
help. Everything else seems fine, since if there's voodoo involved, it
had best be sticking out from the text in big, bloody, blinking, red
letters.

I know, there's noone preventing me from doing otherwise (except for
that blasted __init__). I'd like to follow the pack here, tho.
Stephen

[Hendrik van Rooyen]

"Dan Lenski" <dl*****@gmail. comwrote:

I think part of learning to think like a computer is learning to stop
associating computer logic too strongly with the natural language
meanings of "and", "or", and "not".

This is true - and you have left out "but"....

- Hendrik

[Steven D'Aprano]

On Tue, 14 Nov 2006 12:01:05 +0000, Antoon Pardon wrote:

On 2006-11-13, Ben Finney <bi************ ****@benfinney. id.auwrote:

>Michael Hobbs <mi**@hobbshous e.orgwrites:

>>To be clear, this is the actual thrust of my argument. It seems
redundant to have *both* line continuations and colons in compound
statements.

Why are you trying to remove redundancy?

Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

Redundancy in *what*?

Redundancy is not something to be valued for its own sake. It is only
valuable when it actually gains you something.

e.g. x + y and x.__add__(y) are redundant, BUT __add__ is necessary for
operator overloading and + operator is necessary for readability and
easy arithmetic expressions.

Likewise, operator.add is useful for local optimizations, and so is to be
valued despite the redundancy of yet another way to do addition.

But a hypothetical built-in function add(x,y) =x+y would be redundant
for no good reason, and therefore to be resisted.

The question is not "is the colon redundant?" but "is the colon useful
despite, or even because, its redundancy?". There are two schools of
thought:

(1) Yes, it is useful, *because* of its redundancy -- it helps the human
reader parse and comprehend the source code.
Evidence given: usability studies by the ABC project.

(2) No, it is not useful, because the computer parser doesn't need it.
Evidence given: "it seems to me" repeated loudly until our ears bleed.

People's intuition is notoriously poor at judging usability. I don't say I
give it zero credence, but I give it very little.
--
Steven D'Aprano

[Antoon Pardon]

On 2006-11-15, Steven D'Aprano <st***@REMOVEME .cybersource.co m.auwrote:

On Tue, 14 Nov 2006 12:01:05 +0000, Antoon Pardon wrote:

>On 2006-11-13, Ben Finney <bi************ ****@benfinney. id.auwrote:

>>Michael Hobbs <mi**@hobbshous e.orgwrites:

To be clear, this is the actual thrust of my argument. It seems
redundant to have *both* line continuations and colons in compound
statements .

Why are you trying to remove redundancy?

Why not? My impression is that removing redundancy is considered
a positive thing here in c.p.l.

Redundancy in *what*?

Redundancy in whatever proposal the opponent doesn't like.

Redundancy is not something to be valued for its own sake. It is only
valuable when it actually gains you something.

In the same way it is not something to be eliminated for its own
sake. But if someone doesn't like a particulare proposal and
the proposal happens to introduce some redundancy then there is
a reasonable chance the proposal will be dismissed by simply
observing that it introduces redundancy.

The question is not "is the colon redundant?" but "is the colon useful
despite, or even because, its redundancy?". There are two schools of
thought:

(1) Yes, it is useful, *because* of its redundancy -- it helps the human
reader parse and comprehend the source code.
Evidence given: usability studies by the ABC project.

I wonder, did this project also studied the readability of:

if a == b then

(2) No, it is not useful, because the computer parser doesn't need it.
Evidence given: "it seems to me" repeated loudly until our ears bleed.

A pity that no such study seems to exists concerning code that uses
only indentation to mark structure and code that uses indentation
and some kind of delimiter for showing the boundaries of (sub)
structures. Because the evidence for end markers not being usefull
seems to fall in the same category as (2) here above.

--
Antoon Pardon