What GUI toolkit looks the best?

[Paul Rubin]

I've been approached about writing a Windows app which will need a
really professional looking GUI. Forget TKinter, this has to actually
look good (real artists will be available to get the visual stuff
right). Assuming I write in Python, what's the best toolkit to use?
Some cost in implementation pain is tolerable if the finished
interface looks better as a result. It would be nice if the toolkit
runs on multiple platforms rather than being Windows-only.

I'm thinking Glade. Is that reasonable? I don't know squat about
Windows and haven't done much fancy GUI programming since the early X
days.

Thanks.

[Jarek Zgoda]

Cameron Laird <cl****@lairds.com> pisze:

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.

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/

[Paul Rubin]

Jarek Zgoda <jz****@gazeta.usun.pl> writes:

It surprises me that you write that. I regard Tcl as the
language which has gone the farthest in internationalization,

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]

Jarek Zgoda <jz****@gazeta.usun.pl> pisze:

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.

--
Jarek Zgoda
Unregistered Linux User #-1
http://www.zgoda.biz/ JID:zg***@chrome.pl http://zgoda.jogger.pl/

[Hans-Joachim Widmaier]

Jamey Cribbs <jc*****@twmi.rr.com> wrote in message news:<zF******************@fe3.columbus.rr.com>...

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