GTK complains wildly when I try to update my UI from a different
(python) therad. Basic things like updating the status bar. In fact my
whole painting goes a little crazy after that. I know wxThread is not
listed as implemented. Is there a way to work around these limitations?
Thanks!
Leo.
···
========================================================================
Leonardo B. Lopes leo@iems.nwu.edu
Ph.D. Student (847)491-8470
IEMS - Northwestern University http://www.iems.nwu.edu/~leo
GTK complains wildly when I try to update my UI from a different
(python) therad. Basic things like updating the status bar. In fact my
whole painting goes a little crazy after that. I know wxThread is not
listed as implemented. Is there a way to work around these limitations?
You would have the same troubles from C++ using wxThread, it doesn't do
anything magical...
On most platforms the GUI is not thread-safe so you need to organize your
program such that all calls to GUI objects/methods/etc. happen in the main
thread. (For wxPython this means the thread that was active when
wxPython.wx was first imported.)
One way to do this in wxPython is to send events from your worker threads to
the gui thread. See the threads sample in the demo for more details, but
essentially you derive a class from wxPyEvent, create an instance of it when
needed and send it to the window that is expecting it with
wxPostEvent(window, event). The window catching the event just needs to
define and connect an event handler that does the update of the GUI.
Another method is similar but avoids the event system. The worker threads
can add objects with details about what to update to a Queue (see the
standard Python library Queue.py) and then call wxWakeUpIdle(). The GUI
thread will activate the idle handlers as soon as possible (either
immediately or after any pending events are processed.) You then need to
have an EVT_IDLE handler in your main frame or where ever makes sense that
reads items from the queue and knows how to turn them into GUI updates.