GUIs: wxPython vs. Tkinter (and others)

[Erik Johnson]

I am looking for some input on GUI libraries. I want to build a
Python-driven GUI, but don't really understand the playing field very well.
I have generally heard good things about wxPython. I happen to already own
John Grayson's book about Tkinter programming, so that is rather handy if I
decide to use Tkinter. I have done some things slightly more involved than
"Hello World" in Tkinter - I have never used wxPython. So, basically the
points I am looking to have illuminated are:

o What features does wxPython offer that Tkinter cannot (and vice
versa)?
o Is the general programming methodology pretty much the same between
the two (e.g., the general program structure - using callbacks & Frames,
etc. is the same, it's just a question of calling different widgets with
their own arguments)?
o Do you have a strong preference for one over the other (or some other
toolkit)? Why?
o Are there any platform and/or performance issues I should be aware of?
o Is animation and graphics particularly better suited to one over the
other?
o Other important contrasts/similarities I should be aware of?

So... I know this question must come up fairly often. I did do a search
for "wxPython" and "Tkinter" - of the articles I currently have visibility
of, I saw one bug in wxPython discussed and nothing about Tkinter. Anything
else than can contribute to a "bird's eye view" understanding of the two (or
other) toolkits would be appreciated.

Thanks for taking the time to read my post.

Sincerely,
-ej

[Mike Meyer]

"Erik Johnson" <sp**@nospam.org> writes:

I am looking for some input on GUI libraries.
Since you said others, I'll recommend PyQt. Major downside with it is
that it costs money on Windows.
o What features does wxPython offer that Tkinter cannot (and vice
versa)?
I don't know about wxPython, but PyQt includes it's own threading
facility, plus hooks to talk to databases. It also has a widget for
creating Windows "wizards" for walking through a set of options.
o Is the general programming methodology pretty much the same between
the two (e.g., the general program structure - using callbacks & Frames,
etc. is the same, it's just a question of calling different widgets with
their own arguments)?
Not for Qt. It has the notion of SLOTs and SIGNALs. You connect a
signal from an object to a slot or signal on another (or the same)
object. You can, for example, connect a signal from a slider widget to
a slot on a digital display widget, thus causing the display to change
as you move the slider.

At the python level, slots are just callable objects. At the
C++ level, slots are magic methods of objects. Signals are usually
associated with GUI events, but Python can emit them for whatever
reason it wants. It's possible to connect C++ signals to C++
slots/signals in Python, meaning that Python won't be involved when
that signal is emitted.
o Do you have a strong preference for one over the other (or some other
toolkit)? Why?
I strongly prefer PyQt TkInter. PyQt provides a higher level of
abstraction.
o Is animation and graphics particularly better suited to one over the
other?

I've never tried doing animation in TkInter. Qt provides timer devices
that you can use to drive animations. I suspect that doing the same in
TkInter would be noticably more difficult.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

I've never tried doing animation in TkInter. Qt provides timer devices
that you can use to drive animations. I suspect that doing the same in
TkInter would be noticably more difficult.

Tkinter supports some kind of event that runs n millisecond (n is a
parameter) after you call the method. You can use that to create a
timing loop. That's more or less what you have to do anyway, if you
want to run your tkinter gui in a separate thread from the rest of
your application. Tkinter isn't thread-safe, so you have to do
something like periodically check a queue from the tkinter thread.

[Fredrik Lundh]

Mike Meyer wrote:

I don't know about wxPython, but PyQt includes it's own threading
facility, plus hooks to talk to databases.
That would of course be a great argument if Python didn't already have
a threading facility, and a standard API for talking to databases with
implementations for all major players.
It also has a widget for creating Windows "wizards" for walking
through a set of options.
Besides the fact that wizards isn't really that great (read Cooper), if your
toolkit doesn't let you create a dialogue with a couple of buttons and a
swappable frame, it's not a very good toolkit. (that's very easy, in both
Tkinter and wxPython. You can probably find ready-made modules on
the net if you look around a little)

o Is the general programming methodology pretty much the same between
the two (e.g., the general program structure - using callbacks & Frames,
etc. is the same, it's just a question of calling different widgets with
their own arguments)?

Not for Qt. It has the notion of SLOTs and SIGNALs. You connect a
signal from an object to a slot or signal on another (or the same)
object. You can, for example, connect a signal from a slider widget to
a slot on a digital display widget, thus causing the display to change
as you move the slider.

At the python level, slots are just callable objects. At the
C++ level, slots are magic methods of objects. Signals are usually
associated with GUI events, but Python can emit them for whatever
reason it wants. It's possible to connect C++ signals to C++
slots/signals in Python, meaning that Python won't be involved when
that signal is emitted.

That's would of course be a great argument if you didn't have Python.
(even if Python's slower than C++, it's a lot faster than a user).

If you want bind an event source (signal) to a slot (method) in one line,
use a lambda. If you need to add more behaviour (you usually do), use
a function.
PyQt provides a higher level of abstraction.
Whan what? C++ plus a low level UI API, sure. But Tkinter+Python?
wxPython+Python? You gotta be kidding.

(or you're borrowing it from Trolltech's marketing material; I notice that
the phrase "higher level of abstraction" is very popular amont Qt fans, but
Trolltech themselves only seem to use it when they talk about lower-level
libraries like X/Xt/Motif and the native Win32 API)
I've never tried doing animation in TkInter. Qt provides timer devices
that you can use to drive animations. I suspect that doing the same in
TkInter would be noticably more difficult.

Eh? You don't know how to do a loop in Python? Or register a callback?
wxPython contains both timers and a low-level graphics API; for Tkinter,
you the "after" facility and the Canvas; if you need lower-level drawing
with tighter Python intergration, use the WCK.

(for more advanced drawing, I'd recommend OpenGL, which is available
for them all)

</F>

[Jarek Zgoda]

Fredrik Lundh wrote:

I don't know about wxPython, but PyQt includes it's own threading
facility, plus hooks to talk to databases.

That would of course be a great argument if Python didn't already have
a threading facility, and a standard API for talking to databases with
implementations for all major players.

Python threading is not perfect in many cases in GUI programming -- you
have to implement your own notification mechanism (eg. using queue
polling), as usually you can communicate with GUI only from main
application's thread. While this is the case also for Qt, QThread
instances have ability to post events to any arbitrary Qt objects, thus
making life a bit easier.

Anyway, all of above mentioned toolkits have its own pros and cons and
in most of cases choice is a matter of personal taste.

--
Jarek Zgoda
http://jpa.berlios.de/ | http://www.zgodowie.org/

[Peter Hansen]

Jarek Zgoda wrote:

Fredrik Lundh wrote:

I don't know about wxPython, but PyQt includes it's own threading
facility, plus hooks to talk to databases.

That would of course be a great argument if Python didn't already have
a threading facility, and a standard API for talking to databases with
implementations for all major players.

Python threading is not perfect in many cases in GUI programming -- you
have to implement your own notification mechanism (eg. using queue
polling), as usually you can communicate with GUI only from main
application's thread.

With wxPython, PostEvent (which is what CallAfter also uses) is
threadsafe and can be used from any thread, allowing you to
communicate (in this direction, at least) with the GUI thread
from any regular Python thread. No need for special threads
provided by the framework and, in fact, even though wxWidgets
(on which wxPython is built) provides a wxThread class, it
is not exposed in wxPython because it is redundant there.

-Peter

[Mike Meyer]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

Mike Meyer wrote:

It also has a widget for creating Windows "wizards" for walking
through a set of options.

Besides the fact that wizards isn't really that great (read Cooper), if your
toolkit doesn't let you create a dialogue with a couple of buttons and a
swappable frame, it's not a very good toolkit. (that's very easy, in both
Tkinter and wxPython. You can probably find ready-made modules on
the net if you look around a little)

While I'm not a big fan of wizards, for some applications they are
just the ticket, as you're walking down a tree of options. Presenting
the user the options at each node is exactly the way to go. Sure, it
may be easy to roll your own in TkInter, but in PyQt you don't have to.

At the python level, slots are just callable objects. At the
C++ level, slots are magic methods of objects. Signals are usually
associated with GUI events, but Python can emit them for whatever
reason it wants. It's possible to connect C++ signals to C++
slots/signals in Python, meaning that Python won't be involved when
that signal is emitted.

That's would of course be a great argument if you didn't have Python.
(even if Python's slower than C++, it's a lot faster than a user).

It's still nice to be able to let the C++ code handle it all. After
all, having the compiled layer do things for you is what makes for
fast python code.

PyQt provides a higher level of abstraction.

Whan what? C++ plus a low level UI API, sure. But Tkinter+Python?
wxPython+Python? You gotta be kidding.

No, I'm not kidding. I'm stating my general impression after having
done programming with both TkInter and PyQt. Note, that's *Py*Qt, not
Qt.

I've never tried doing animation in TkInter. Qt provides timer devices
that you can use to drive animations. I suspect that doing the same in
TkInter would be noticably more difficult.

Eh? You don't know how to do a loop in Python? Or register a callback?
wxPython contains both timers and a low-level graphics API; for Tkinter,
you the "after" facility and the Canvas; if you need lower-level drawing
with tighter Python intergration, use the WCK.

Sure, you can roll a loop together with a sleep and do animation. You
can throw in threading and queues so you can keep the GUI active while
you're doing it. With Qt, you tie the timer's signal to the
object-moving function, and you're done. Since you have to use the
threaded version to get the same functionality, I'd say noticably more
difficult isn't an overstatement.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[info]

Hi, I had very bad experience with Tkinter when using input servers(for
CJK languages like scim, xcin...) on Linux (doesn't work), so you might
consider this.

[Eric Brunel]

in**@klubko.net wrote:

Hi, I had very bad experience with Tkinter when using input servers(for
CJK languages like scim, xcin...) on Linux (doesn't work), so you might
consider this.

Eh? I use (not frequently, I admit...) kinput2 with canna and wnn servers with
Tkinter on Linux and it works quite smoothly. Can you describe what happens to
you exactly?
--
- Eric Brunel <eric (underscore) brunel (at) despammed (dot) com> -
PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com