469,282 Members | 1,977 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,282 developers. It's quick & easy.

How to choose the right GUI toolkit ?

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_end_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 "heavyweight".
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 professionalness 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 "lightweight"
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

Nov 8 '06 #1
161 4824
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/
Nov 8 '06 #2

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

Nov 8 '06 #3
John Salerno <jo******@NOSPAMgmail.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
Nov 9 '06 #4
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 ;)
Nov 9 '06 #5
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
Nov 9 '06 #6
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.
Nov 9 '06 #7
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

Nov 9 '06 #8
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

Nov 9 '06 #9
In <ma***************************************@python. 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
Nov 9 '06 #10
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'
Nov 9 '06 #11
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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Nov 9 '06 #12
Nick Craig-Wood wrote:
John Salerno <jo******@NOSPAMgmail.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

Nov 9 '06 #13
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

Nov 9 '06 #14
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 )
Nov 9 '06 #15
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/
Nov 9 '06 #16
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
Nov 9 '06 #17
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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Nov 9 '06 #18
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

Nov 9 '06 #19
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.
Nov 9 '06 #20

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.

Nov 9 '06 #21
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.
Nov 9 '06 #22
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

Nov 9 '06 #23
On 2006-11-09, John Salerno <jo******@NOSPAMgmail.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
Nov 9 '06 #24
>>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_separation.
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


Nov 9 '06 #25
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.

Nov 9 '06 #26
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 +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

Nov 9 '06 #27
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

Nov 9 '06 #28
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.

Nov 9 '06 #29
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.

Nov 9 '06 #30


Steve Holden wrote:
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).
It all depends on what you need. You can always "drop down" to calling
wxPython.
I don't think PythonCard gets much maintenance nowadays.
Funny you mention that. I started that discussion on the PythonCard
list only yesterday.

While it's true that the web pages hasn't been updated to follow up
with the developments, I am delighted to learn that there has been
quite a bit of work going on.

Again, it all depends on what your needs are. If you need to become
productive in a hurry, and you are not exactly chasing after the
latest widget, my recommendation is to go with PythonCard.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
Nov 9 '06 #31
Tim Chase wrote:
A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)
Well, it's neither arbitrary nor simply the preference of the BFDL. The ABC
project actually did empirical experiments with programmers to find that code
comprehension improved by adding the colon.

Here's a post from Uncle Timmy mentioning it:

http://groups.google.com/group/comp....568e684d653003

Unfortunately, my Google-fu has not located an actual paper. It might be in here
somewhere:

http://homepages.cwi.nl/~steven/abc/publications.html

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

Nov 9 '06 #32
One other thing I'm wondering: how exactly does Tkinter work? Is the
whole Tk toolkit bound up as library of low-level C code, or does
Tkinter sit on top of a Tcl interpreter?

If the latter, that might explain why it is frustratingly slow on
Cygwin... since Cygwin is not very good at starting up new processes in
a timely manner.

Dan

Nov 9 '06 #33
Please don't hide your new thread as a reply to an existing, unrelated
message. Start a new message if your message isn't actually a reply.

Michael Hobbs <mi**@hobbshouse.orgwrites:
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()
But it can't be dropped from this statement:

if self.hungry: 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()
Why have two different syntaxes for the same statement?
I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing
anything?
A use case. What problem is being solved by introducing this
inconsistency?

--
\ "The shortest distance between two points is under |
`\ construction." -- Noelie Alito |
_o__) |
Ben Finney

Nov 9 '06 #34
Ben Finney wrote:
I think the colon could be omitted from every type of compound
statement: 'if', 'for', 'def', 'class', whatever. Am I missing
anything?

A use case. What problem is being solved by introducing this
inconsistency?
I agree completely. And as a recent convert to Python, I have to say
that I *like* the colons. I found the whitespace-and-colon thing
really irritating... for about 2 hours.

The colon makes it easier to eyeball where a block statement begins in
the absence of braces around the block, it allows one-line if
statements (which I use a lot), and it means that even the stupidest,
simplest editor can figure out where auto-indentation is needed, namely
following any line that ends with a colon (except in a triple-quoted, I
guess).

Contrast that with Perl, where in years of professional and hobby use I
have not found a single editor that gets indentation right more than
about 90% of the time. The syntax is too darn complicated. With
Python, figuring out where to auto-indent is trivial. Works for me.

Dan

Nov 9 '06 #35
On 8 Nov 2006 11:49:07 -0800, "John Henry" <jo**********@hotmail.com>
wrote:
>
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

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?

Bill
================================================== ===================
My notes from Fri Dec-23-2005:

This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.

I installed yesterday, using this installer:
PythonCard-0.8.1.FIXED.win32.exe

A) The very first example in the tutorial is wrong!

On this page: http://pythoncard.sourceforge.net/documentation.html
When you follow this link to try something for the very first time:

Getting Started in PythonCard by Dan Shafer:
http://pythoncard.sourceforge.net/walkthrough1.html

You quickly see that the minimal.py example doesn't even contain
this line, even though the tutorial refers to it:

def on_menuFileAbout_select(self, event):

And, of course, if you replace the word "pass" with this, as
instructed:

result = dialog.alertDialog(self, 'It works!', 'Showing Off')

it won't run, because the existing "pass" line isn't inside a def
inside of a class.
B) Is the Notebook widget really supported?

In the installed file "changelog.txt" (gets installed as part of
PythonCard installation), it says:

"added Notebook component, PageBackground, and testNotebook
sample"

But, the testNotebook sample is nowhere to be found.

I looked lots of places, including the main SourceForge web site,
and on the wiki, here:

http://wiki.wxpython.org/index.cgi/PythonCard

Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
me, concerning the availability of the notebook component:

http://aspn.activestate.com/ASPN/Mai...oncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp....ythoncard/1060

where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).

To add insult to injury, after you download the zip file with the
testNotebook stuff, the readme file says this:

"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

C) Are the websites being maintained?
Nov 10 '06 #36
Bill Maxwell wrote:
On 8 Nov 2006 11:49:07 -0800, "John Henry" <jo**********@hotmail.com>
wrote:

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


I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?

Bill
================================================== ===================
My notes from Fri Dec-23-2005:

This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.

I installed yesterday, using this installer:
PythonCard-0.8.1.FIXED.win32.exe

A) The very first example in the tutorial is wrong!

On this page: http://pythoncard.sourceforge.net/documentation.html
When you follow this link to try something for the very first time:

Getting Started in PythonCard by Dan Shafer:
http://pythoncard.sourceforge.net/walkthrough1.html

You quickly see that the minimal.py example doesn't even contain
this line, even though the tutorial refers to it:
I am not sure which one you are referring to but in the
PythonCard\samples\minimal, you will find a minimal.py that says:

#!/usr/bin/python

"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""

from PythonCard import model
class Minimal(model.Background):
def on_menuFileAbout_select(self, event):
pass

if __name__ == '__main__':
app = model.Application(Minimal)
app.MainLoop()
def on_menuFileAbout_select(self, event):

And, of course, if you replace the word "pass" with this, as
instructed:

result = dialog.alertDialog(self, 'It works!', 'Showing Off')

it won't run, because the existing "pass" line isn't inside a def
inside of a class.
No, it didn't work because the author forgot to mention that you have
to do a:

from PythonCard import model, dialog

instead of just:

from PythonCard import model

I just tried it and it works.
>
B) Is the Notebook widget really supported?

In the installed file "changelog.txt" (gets installed as part of
PythonCard installation), it says:

"added Notebook component, PageBackground, and testNotebook
sample"

But, the testNotebook sample is nowhere to be found.
I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

I looked lots of places, including the main SourceForge web site,
and on the wiki, here:

http://wiki.wxpython.org/index.cgi/PythonCard

Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.
Yes, sometime around 2004, the website updating stopped. Fortunately,
development didn't. There are quite a number of new things since then:
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.

Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
me, concerning the availability of the notebook component:

http://aspn.activestate.com/ASPN/Mai...oncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp....ythoncard/1060

where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).

To add insult to injury, after you download the zip file with the
testNotebook stuff, the readme file says this:

"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."

As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

C) Are the websites being maintained?

It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.

I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.

Cheers.

Nov 10 '06 #37
Upon closer look, the walkthrough did say:

***************************
from PythonCard import model

Change that so it says:

from PythonCard import dialog, model

Save the code.
***************************

So, it works.

John Henry wrote:
Bill Maxwell wrote:
On 8 Nov 2006 11:49:07 -0800, "John Henry" <jo**********@hotmail.com>
wrote:
>
>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

I took a brief look at PythonCard almost a year ago and got discouraged
by what I found, so I stopped looking at it. I've inserted my notes
from back then, below. Does anybody know if these things have been
fixed in the latest release?

Bill
================================================== ===================
My notes from Fri Dec-23-2005:

This is a list of gripes I have while trying to learn about PythonCard.
I'm trying to investigate various GUI builders for Python, and
PythonCard looks promising, but a lot of things are getting in the way.

I installed yesterday, using this installer:
PythonCard-0.8.1.FIXED.win32.exe

A) The very first example in the tutorial is wrong!

On this page: http://pythoncard.sourceforge.net/documentation.html
When you follow this link to try something for the very first time:

Getting Started in PythonCard by Dan Shafer:
http://pythoncard.sourceforge.net/walkthrough1.html

You quickly see that the minimal.py example doesn't even contain
this line, even though the tutorial refers to it:

I am not sure which one you are referring to but in the
PythonCard\samples\minimal, you will find a minimal.py that says:

#!/usr/bin/python

"""
__version__ = "$Revision: 1.8 $"
__date__ = "$Date: 2005/12/17 15:20:02 $"
"""

from PythonCard import model
class Minimal(model.Background):
def on_menuFileAbout_select(self, event):
pass

if __name__ == '__main__':
app = model.Application(Minimal)
app.MainLoop()
def on_menuFileAbout_select(self, event):

And, of course, if you replace the word "pass" with this, as
instructed:

result = dialog.alertDialog(self, 'It works!', 'Showing Off')

it won't run, because the existing "pass" line isn't inside a def
inside of a class.

No, it didn't work because the author forgot to mention that you have
to do a:

from PythonCard import model, dialog

instead of just:

from PythonCard import model

I just tried it and it works.

B) Is the Notebook widget really supported?

In the installed file "changelog.txt" (gets installed as part of
PythonCard installation), it says:

"added Notebook component, PageBackground, and testNotebook
sample"

But, the testNotebook sample is nowhere to be found.

I haven't come across a need to use Notebook and so I can not say for
sure. Looking at notebook.py, it appears to be just a simple wrapper
on top of the wxWindow notebook. I would encourage you to post a
message to the mailing list and ask there.

I looked lots of places, including the main SourceForge web site,
and on the wiki, here:

http://wiki.wxpython.org/index.cgi/PythonCard

Both the main website and the wiki seem way out of date, and the
latest dates I could find on both of them are sometime in 2004.

Yes, sometime around 2004, the website updating stopped. Fortunately,
development didn't. There are quite a number of new things since then:
new resource editor (now call layout Editor, standalone exe creator,
and so forth). I even learn that a new sizer handler is in the work.

Not saying that there are 10 programmers working 7/24 on it. It *is*
an Open Source project nevertheless. Nobody gets paid for doing it.
But there are development work going on.

Finally, by following the mailing list archive link on the main
website, I managed to find a reference to the notebook component on the
ASPN site, where some guy named Brian wonders about the same thing as
me, concerning the availability of the notebook component:

http://aspn.activestate.com/ASPN/Mai...oncard/2536825

and, that message led me here:

http://article.gmane.org/gmane.comp....ythoncard/1060

where Kevin Altis admits that he forgot to include it in the 0.8.1
release! At least he provides a way to download it separately. But,
gheesh, this is pretty poor for a new user. I was interested in using
the notebook component right away, because I looked at the wxGlade
tutorial before looking at PythonPage, and they use the notebook
component in their example (and I decided I really want to use the
component).

To add insult to injury, after you download the zip file with the
testNotebook stuff, the readme file says this:

"Until we have a Notebook integrated into some of the other
samples or tools this will serve as a basic test app, but I don't expect
to include it in releases."


As with all Open Source projects, your mileage differs. PythonCard
does what *I* need to get done - and allowed me to get it done in a
*hurry*. May be you really need Notebook and may be it's true that
Notebook really doesn't work, I don't know. But if you managed to get
it working, write it up and get it included. That's what Open Source
Projects are all about.

C) Are the websites being maintained?


It appears that the maintainer of the web site stopped updating it
since late 2004. I don't know why. May be he's been busy. May be he
got mad. I don't know. All I know is that I have been very
productive with what I need to get done (and earned a happy living with
the code I created) and I am very grateful to the people that worked on
it - past and present.

I am not a "professional programmer" and so I probably can't contribute
to the development effort itself. However, I've gotten pretty good in
using most of the package (other then Notebook, I admit). So, if you
have any specific questions, please post it to the PythonCard list and
I'll try to help if I can.

Cheers.
Nov 10 '06 #38
On Thu, 09 Nov 2006 23:51:31 +0100, Dan Lenski <dl*****@gmail.comwrote:
One other thing I'm wondering: how exactly does Tkinter work? Is the
whole Tk toolkit bound up as library of low-level C code, or does
Tkinter sit on top of a Tcl interpreter?
The latter: there is a tiny C layer allowing Python to call an embedded
tcl interpreter.
If the latter, that might explain why it is frustratingly slow on
Cygwin... since Cygwin is not very good at starting up new processes in
a timely manner.
There is no other process involved: the interpreter is embedded, just as a
Python interpreter can be embedded in a C application. If you want to work
with Tkinter on Windows, you'd better avoid Cygwin. Python with Tkinter
works just fine on Windows, just as it works on any other platform, and is
fully portable, just as tcl/tk is.

HTH
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Nov 10 '06 #39
On Thu, 09 Nov 2006 22:01:51 +0100, Dan Lenski <dl*****@gmail.comwrote:
Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP.
It seems to depend on the widget type, and on what you call native... For
example, tk menus are definitely the native ones; tk scrollbars are the
native ones, but with the Win2k look (no XP look available yet); tk
buttons do not seem to be the native ones, as they don't act like "normal"
Windows buttons.
But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop.
You seem to imply that GTK is "native" on Linux. It isn't, as can be seen
with the echoes of the "holy war" between Gnome and KDE that we often see
around here. As an aside, I personnally work on Linux and don't even use
any of these environments (both are too much Windows-like to my taste...).
Is there a way to get it to do so?
Not yet. But tcl/tk 8.5 will include the Tile extension including new
themable widgets. See here:
http://tktable.sourceforge.net/tile/...hots/unix.html

There is also a Tile/QT extension that allows the Tile widgets to use the
QT library. See here:
http://www.ellogon.org/petasis/index...d=24&Itemid=40

AFAIK, nothing equivalent for GTK yet.

HTH
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Nov 10 '06 #40
Dan Lenski wrote:
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.
You normally use PyQt/Qt on Windows without Cygwin. There are very few bugs
and lots of professional companies base their products on Qt Windows.

--
Jeremy Sanders
http://www.jeremysanders.net/
Nov 10 '06 #41
On 2006-11-10, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On Thu, 09 Nov 2006 14:44:21 -0600, Tim Chase
<py*********@tim.thechases.comdeclaimed the following in
comp.lang.python:
>A few arbitrary warts per-dictum of BDFL are fine though...it
still looks much cleaner compared to PHP & Perl ;-)
Or line continuation in REXX... Where you get such oddities as:

call xyz(a, b, c, ,
d, e, f)

That is NOT a NULL argument between c and d... The first comma
is the argument separator, the second comma is the
to-be-continued marker
Eyiyi! That's yugly.

The colon's main purpose seems to be to allow one-liners:

Easy to parse: if a < b: a += 1
Hard to parse if a < b a += 1

--
Neil Cerutti
When you're in the public eye, it's wrong to cheat on someone, unless
you're very careful. If you're normal and no one's going to know, then
do it. --Paris Hilton
Nov 10 '06 #42

NeilThe colon's main purpose seems to be to allow one-liners:

NeilEasy to parse: if a < b: a += 1
NeilHard to parse if a < b a += 1

No, as the note from Tim Peters referenced by Robert Kern pointed out
earlier in this thread, the ABC language designers found that
indentation-based block structure by itself wasn't enough to clue new users
in about the code structure. Adding the colon at the end of the
if/while/for clause helped.

Skip

Nov 10 '06 #43
On 2006-11-09, Bjoern Schliessmann
<us**************************@spamgourmet.comwrote :
What about

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

:)
The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that. The disadvantage is that the
usual binary logical operators must exist and are spelled
differently. (It uses C's '||' and '&&'.)

if (color == red or blue or green && color.type == additive) {
return 'primary';
}

It also supports a switch statement syntax and semantics that
would fit nicely with Python.

switch (action) {
Eat:
print "Gulp! Delicious, but poisonous.";
deadflag = 1;
Taste:
print "You nibble at one of the corners. Yum!";
Attack:
print "What did that mushroom ever to to you?";
default:
print "You can't do that to a mushroom.";
}

There's no fall-through, and there's no syntax to enable it,
either.

In Python it would hypothetically be:

switch action:
Eat:
print "Gulp! Delicious, but poisonous."
deadflag = True
Taste:
print "You nibble at one of the corners. Yum!"
Attack:
print "What did the mushroom ever to to you?"
default:
print "You can't do that to a mushroom."

I've often wanted a "Pythonic" Inform to Inform translator, so I
can leave out all the unecessary (), {} and ;.

* Inform 6 is a language for implementing text adventures, not
to be confused with the unrelated language Inform 7.

--
Neil Cerutti
Nov 10 '06 #44

NeilThe colon's main purpose seems to be to allow one-liners:

NeilEasy to parse: if a < b: a += 1
NeilHard to parse if a < b a += 1

Skip... the ABC language designers found that indentation-based block
Skipstructure by itself wasn't enough to clue new users in about the
Skipcode structure. Adding the colon at the end of the if/while/for
Skipclause helped.

One final note. Just because the colon isn't technically required in many
situations doesn't mean it's superfluous. If all language designers cared
about was ease of parsing we'd probably all be programming in assembler,
sendmail, brainfuck. Or, as the Zen of Python says: "Readability counts".

Skip

P.S. I felt I just had to tie this into the thread on profanity somehow.
But notice that I didn't mention nazis or Hitler. ;-)

S
Nov 10 '06 #45
Christophe <ch*************@free.frwrote:
( 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 )
If you install the QT theme for GTK it all starts to look a lot nicer

Eg debian

ii gtk2-engines-gtk-qt 0.7-1 theme engine using Qt for GTK+ 2.x

You get a control panel for GTK apps in the KDE control center also.

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Nov 10 '06 #46
On 2006-11-10, sk**@pobox.com <sk**@pobox.comwrote:
>
NeilThe colon's main purpose seems to be to allow one-liners:

NeilEasy to parse: if a < b: a += 1
NeilHard to parse if a < b a += 1

No, as the note from Tim Peters referenced by Robert Kern
pointed out earlier in this thread, the ABC language designers
found that indentation-based block structure by itself wasn't
enough to clue new users in about the code structure. Adding
the colon at the end of the if/while/for clause helped.
Thanks. I worded that lousily.

--
Neil Cerutti
The Minutemen are not tall in terms of height. --Dan Bonner
Nov 10 '06 #47

Eric Brunel wrote:
On Thu, 09 Nov 2006 22:01:51 +0100, Dan Lenski <dl*****@gmail.comwrote:
Tk 8.4 appears to use native Win32 widgets under Cygwin and native
WinXP.

It seems to depend on the widget type, and on what you call native... For
example, tk menus are definitely the native ones; tk scrollbars are the
native ones, but with the Win2k look (no XP look available yet); tk
buttons do not seem to be the native ones, as they don't act like "normal"
Windows buttons.
So, basically, Tk is actually embedding the native Win2k menus, but it
isn't actually embedding the native Win2k scrollbars... it's just
emulating their look and feel?
But it definitely doesn't use GTK widgets under Ubuntu with
Gnome desktop.

You seem to imply that GTK is "native" on Linux. It isn't, as can be seen
with the echoes of the "holy war" between Gnome and KDE that we often see
around here. As an aside, I personnally work on Linux and don't even use
any of these environments (both are too much Windows-like to my taste...).
I didn't imply that GTK widgets are "native" on Linux. I implied that
GTK widgets native under Gnome ;-) I was basing my assumption on an
earlier poster who said that Tk 8.x can use native widgets on all
supported platforms... so I assumed that under Gnome it should use GTK
widgets.
Is there a way to get it to do so?

Not yet. But tcl/tk 8.5 will include the Tile extension including new
themable widgets. See here:
http://tktable.sourceforge.net/tile/...hots/unix.html
Good to know! I'm looking forward to 8.5.

Dan

Nov 10 '06 #48
I highly recommend wxPython. It's very mature, full-featured, and
portable, and fairly easy to learn as well.
I am also a Python beginner thinking about what GUI toolkit to use, and
the availability of a free video screencast series on installing and
using wxpython at showmedo.com is making me want to go that way. I
viewed their introduction to Python resources and wished I had found it
first.

The wxpython series is at http://tinyurl.com/yggean

Vincent

Nov 10 '06 #49
Neil Cerutti wrote:
On 2006-11-09, Bjoern Schliessmann
>if color == red or blue or green:
return 'primary'

:)
The Inform 6* programming language supports the serial 'or' (and
'and') and looks just like that.
Python also supports it.
The disadvantage is that the usual binary logical operators must
exist and are spelled differently. (It uses C's '||' and '&&'.)
Do they have to be spelled differently? In Python, they don't have
to.

Regards,
Björn

--
BOFH excuse #115:

your keyboard's space bar is generating spurious keycodes.

Nov 10 '06 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Greg Scharlemann | last post: by
reply views Thread by Chive Software | last post: by
2 posts views Thread by Ney André de Mello Zunino | last post: by
10 posts views Thread by miffy900 | last post: by
6 posts views Thread by Rental | last post: by
2 posts views Thread by krishnakant Mane | last post: by
34 posts views Thread by Anthony Irwin | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.