Tkinter vs wxPython: your opinions?

[Timothy Docker]

thelazydogsback at my-deja.com writes:

> (1) Does one toolkit behave better in a multi-threaded application than
> another? In addition to the design of the toolkit, any kit that uses
> native widgets has native restrictions on threading and the GUI (e.g.,
> only "main" thread talks to the GUI, etc.), so I'd guess that self-draw
> GUIs would have a chance of behaving better here. Also OS-threads would
> have more issues than stackless "microthreads" where re-entrency would
> be the biggest problem (?). When threads spawned from the main thread
> need to update GUI state, what is the standard method used? Does wx's
> doc/view architecture make this more straightforward?

Neither tkinter or wxWindows are thread-safe in the sense that
multiple threads can make arbitrary GUI calls simultaneously (I'm not
aware of any GUI toolkits that are thread-safe in this sense).

Both toolkits work OK using the common approach of making a single
thread responsible for the GUI, and other worker threads for other
purposes. In my opinion, wxWindows does this in a much better way -
there is a wxPostEvent() call that is callable from any thread. It
notifies the GUI thread of some condition, usually by activating some
callback. Arbitrary python data can be attached to the event.

With tkinter, on the other hand, the GUI thread must periodically poll
for some sort of update from a worker thread - meaning that there is
an annoying tradeoff between polling frequency (response time), and
idle cpu usage. I see this as a significant limitation.

> (2) I assume I could have an app the used both wx & tk at the window
> level, but is it possible to host WX inside of Tk, or visa-versa, at
> the frame and/or widget level?

I don't think so.

Tim