What GUI toolkit looks the best?

[Peter Hansen]

When I said "why isn't
there a .write(...) method for these widgets? Why can't I use a text
widget like<a file stream>" that wasn't a specious Robin should do this
for me question. It really was more like, is this a way a text widget
should behave?

That wasn't clear from the wording you used. Thanks for clarifying.
It's a good question... I don't have the answer.

-Peter

 

[Edward K. Ream]

Please don't let one person's experience spoil you on the idea of

at least investigating wxPython for your own use.

Actually, I think we are in "virulent agreement". I have never suggested
writing off wxWindows/wxPython, as Leo's wxPython plugin shows. I merely
suggest due caution.

My experience isn't that wxWindows doesn't work at all, it is that it takes
a lot more work to make wxWindows work as I expect than with, say, Tkinter.
It's a cost/risk issue. I should have made that clearer. wxPython reduces
that cost difference substantially, and Python provides ways of end-running
problems that didn't exist when I was using C++.

Edward

 

[Dave Brueck]

After sleeping on this question, I think not True, my choice of words
wasn't the best, but since you brought up FUD, I'm willing to discuss my
fears, uncertainties and doubts about wxWindows.

Motivation & experience

The typical FUD campaign is driven by ulterior motives. I have no such
motives --I am not the author of a product that competes with wxPython or
Tkinter

Well, I'm not really interested in pressing the issue (I don't have ulterior
motives either ;-) ), but if not FUD, it was inaccurate in the _general sense_
as many applications are built upon wxWindows/wxPython and do not have
problems. I do not doubt that you've experienced problems with that framework;
but I do take issue with the implication that such an experience is the norm -
for example, the wxWindows site has quite a list of examples that use it, and
many of which are quite widely used and certainly not toy applications (AOL
Communicator, Audacity, etc.), so I'd say it _is_ clear that it "actually
works". I have a hard time understanding how wxWindows could be so flaky and
buggy and yet still enjoy such commercial and open source success - why aren't
the people who use it drowning in support calls/emails?

In my experience, it is a _fact_ that wxPython (really wxWindows) seems to
have many more bugs than Tkinter. It is a _rare_ bug that has no
workaround, so this fact does _not_ mean that it is impossible to produce
"working" apps with wxWindows/wxPython. What is probably _does_ mean is
that it will be more expensive to create a solid wxPython app than one would
hope. In my experience, the answer to the question "Why the hell hasn't
wxPython become the standard GUI for Python yet?" is: "wxWindows is buggy."

The good news is that the wxWindows and wxPython developers are pretty good
about fixing bugs, so there's a good chance that all the bugs you found and
reported to them have been fixed by now. ;-)

It was good talking to you. Congrats on your progress with Leo - pretty neat!
-Dave

 

[Mark Roach]

You can build wxWindows with the free (as in free beer) Borland's bcc5.x
compiler, or with free (as in free beer and free speech) compilers like
Minwg's gcc.

but not wxPython. You must use MSVC for compiling on Windows. However,
unless you have patches or extensions to compile, the precompiled version
should work just fine.

-Mark

 

[Peter Hansen]

That wasn't clear from the wording you used. Thanks for clarifying.
It's a good question... I don't have the answer.

And by the way, I do appreciate your efforts on KitViewer and such... apologies
for the slight.

-Peter

 

[Edward K. Ream]

if not FUD, it was inaccurate in the _general sense_

as many applications are built upon wxWindows/wxPython and do not have
problems.

Yeah, as I think about this more, I am tending to agree with you. Perhaps I
was just being too grumpy or pessimistic. I owe the wxWindows people an
apology. Consider it given.

For sure wxPython is pretty easy to use. Looking back, I was letting
earlier trauma color my thinking too much. Also, the wxSTC control might
well solve the problems with the plain wxText control...

Edward

 

[Jarek Zgoda]

My experience isn't that wxWindows doesn't work at all, it is that it takes
a lot more work to make wxWindows work as I expect than with, say, Tkinter.
It's a cost/risk issue. I should have made that clearer. wxPython reduces
that cost difference substantially, and Python provides ways of end-running
problems that didn't exist when I was using C++.

There are times, when Tkinter doesn't work at all, i.e. on
"second-half-of-world" terminals (non-ASCII/non-LATIN1). wxPython has no
problems there. Yes, I know, it's due to flaws in TCL/Tk, not in Tkinter
itself. But all Pythons ship with this flawed, broken, unusable Tk. And
don't even try to argue, that my customers can "build their own Tk with
bcc32 or OpenWatcom", they dont need to do anything more than install
wxPython from readily-available binary distribution.

NP: Sex Pistols - EMI

 

[Paul Rubin]

but not wxPython. You must use MSVC for compiling on Windows. However,
unless you have patches or extensions to compile, the precompiled version
should work just fine.

I've had enough experiences getting stuck in a project due to library
bugs or incorrect documentation that I really want to be able to run
the complete program (including libraries) under a debugger. That
sounds like I need MSVC. However, I guess that's tolerable since this
would be a paid project that needs to run on Windows. Sure, using
MSVC is distasteful, but so is using Windows in the first place, so if
I'm willing to use Windows at all, having to use MSVC as well is just
more of the same. Thanks.

 

[Cameron Laird]

.
.
.

There are times, when Tkinter doesn't work at all, i.e. on
"second-half-of-world" terminals (non-ASCII/non-LATIN1). wxPython has no
problems there. Yes, I know, it's due to flaws in TCL/Tk, not in Tkinter
itself. But all Pythons ship with this flawed, broken, unusable Tk. And
don't even try to argue, that my customers can "build their own Tk with
bcc32 or OpenWatcom", they dont need to do anything more than install
wxPython from readily-available binary distribution.

.
.
.
It surprises me that you write that. I regard Tcl as the
language which has gone the farthest in internationalization,
apart from Java, and the one which makes such delights as
<URL: http://wiki.tcl.tk/3145 > feasible.

Do you know what it is that's broken? There are several
people on both the Tk and Python sides who are eager to learn
of faults, so that they can fix them as soon as possible; I'll
be glad to help you direct your report so that it's resolved
without delay. I raised your comments with the head of Tcl
support at ActiveState; he replied, in part, "Tk was the first
of the open source cross-platform UI toolkits to have full
unicode support, end-to-end. There are no flaws in Tcl/Tk in
this regards, and AFAIK this works just fine in Tkinter as well"
[reproduced with permission].

I agree that wxPython is a fine toolkit. I think there's still
a place for Tkinter, and it sounds as though you have knowledge
about how to help it fit that place better.

 

[JanC]

The (admittedly very cool) wxPython demo regularly
segfaults on Windows. Sheesh.

Were you using the Unicode build on Win95/98/ME?

 

[Jarek Zgoda]

There are times, when Tkinter doesn't work at all, i.e. on
"second-half-of-world" terminals (non-ASCII/non-LATIN1). wxPython has no
problems there. Yes, I know, it's due to flaws in TCL/Tk, not in Tkinter
itself. But all Pythons ship with this flawed, broken, unusable Tk. And
don't even try to argue, that my customers can "build their own Tk with
bcc32 or OpenWatcom", they dont need to do anything more than install
wxPython from readily-available binary distribution.

.
It surprises me that you write that. I regard Tcl as the
language which has gone the farthest in internationalization,
apart from Java, and the one which makes such delights as
<URL: http://wiki.tcl.tk/3145 > feasible.

Do you know what it is that's broken? There are several
people on both the Tk and Python sides who are eager to learn
of faults, so that they can fix them as soon as possible; I'll
be glad to help you direct your report so that it's resolved
without delay. I raised your comments with the head of Tcl
support at ActiveState; he replied, in part, "Tk was the first
of the open source cross-platform UI toolkits to have full
unicode support, end-to-end. There are no flaws in Tcl/Tk in
this regards, and AFAIK this works just fine in Tkinter as well"
[reproduced with permission].

No, I don't mean "broken unicode support", the problem lies in Python
interfacing with Tk, when Python's unicode means something different,
than Tk unicode.

I'll try to produce some examples of erroneous behavior on both X11 and
Windows NT and file bug report on SF.

 

[Paul Rubin]

No, I don't mean "broken unicode support", the problem lies in Python
interfacing with Tk, when Python's unicode means something different,
than Tk unicode.

I thought python supported only 16 bit Unicode so it can't fully
interoperate with a 32-bit implementation.

 

[Jarek Zgoda]

Do you know what it is that's broken? There are several
people on both the Tk and Python sides who are eager to learn
of faults, so that they can fix them as soon as possible; I'll
be glad to help you direct your report so that it's resolved
without delay. I raised your comments with the head of Tcl
support at ActiveState; he replied, in part, "Tk was the first
of the open source cross-platform UI toolkits to have full
unicode support, end-to-end. There are no flaws in Tcl/Tk in
this regards, and AFAIK this works just fine in Tkinter as well"
[reproduced with permission].

No, I don't mean "broken unicode support", the problem lies in Python
interfacing with Tk, when Python's unicode means something different,
than Tk unicode.

I'll try to produce some examples of erroneous behavior on both X11 and
Windows NT and file bug report on SF.

Whops! Seems like I missed totally a whole bunch of nice updates in
Python 2.3, like support for Tk 8.4 and Tcl/Tk 8.4.3 shipping with
Windows version. Scripts that produced some weird results on Python 2.2
now run smoothly...

I am sorry for burden.

 

[Hans-Joachim Widmaier]

I think GTK looks great on Windows and my PyGTK apps have been very
stable and responsive. On a more subjective note, for me, the PyGTK API
just fits my brain better than the wxPython one does. It just feels
more seemless to me and things make more sense when I look at them.
Like I said, pretty subjective.

I've just more or less completed my first program using pyGTK (all my
previous programs used Tkinter). While I could have done this with
Tkinter as well, I decided to change when I was searching for
something like a terminal widget (for still another project, not yet
started) and there was already a nice example with pyGTK. My first
fears of pyGTK needing much more code (as there aren't zillions of
options for the widget creator but hundreds of methods) were
unfounded, and the early code ran quite well.

There are quite a few rough edges, though, predominantly with Windows:

- Under older Windows versions, the default font isn't found, which
causes endless warning assertions. It ignores the rc file so you can't
simply change the font. (Of course you could work around that, but not
trivially, as I understand.)

- The file selection dialog has no line for the floppy disk ('A:').
It's ok for Unix, but looks alien and ugly under Windows.

- I found no way to stack the windows like I want, i.e. my "file
exists, overwrite?"-dialog pops up _below_ the file dialog and isn't
seen. Despite my attempts to close the file selection first and raise
the other. Under Linux this works fine.

- When I create a button with a stock image, I always get a text
beside it. (Like "Open" for STOCK_OPEN.) It takes some hoop-jumping to
get rid of those.

- Under windows, there's no simple installation that just works. You
have to play with the path so the DLLs are found.

Maybe some of my problems are the result of my newbie status.

OTOH, I did try wxPython a few times, and it always crashed on me
while playing with the demo. Besides, I'm a bit reluctant to use a
framework -- I consider Python to be one -- instead of just a GUI
toolkit.

Just my personal experience and thoughts.

Hans-Joachim