> Sure. But my recollection was that gui_thread needed a lot of work
> (Eric Jones told me at least a month!), and it could well be that
> one is needed for each gui (it does mapping of gui requests from
> one thread to another or something like that so that a thread
> running the mainloop allows the python interactive loop to run
> separately. It would be nice if gui's played well with each other,
> but I don't know if that is easy to do (or even workable for
> all combinations). If someone knows how to do this sort of thing
> that would be great, but we don't (neither the resources or expertise).
> At the moment I take the position that it is simplest not to mix
> gui's. The current rule of thumb should be that if you want to
> use a shell that runs under a gui, you need the back end in matplotlib
> to go with that gui.
> I hope someone can make me a liar on that.
Some time back I experimented with gui_thread.
One fairly serious problem with gui_thread is that it is important which
thread wxpython gets imported into.
Eric worked around this by printing a message once gui_thread had been
imported which, interactively was a signal that it was ok to start using
it. There is a README in the gui_thread package which has more details
on this problem.
Now I was interested in gui_thread for two reasons: interactive
plotting with chaco and creating python COM objects which fired up
The latter is a bit challenging + the solution was to run the gui in a
different thread. So I started off using gui_thread. I had to re-work
the gui_thread code a bit, the trick was to do a bit less work when
importing gui_thread so that I had better control of when wxpython was
imported and hence could make sure it all happened in the right
threads. I fed the fixes back to Eric, but I don't think he wanted to
change the semantics of gui_thread + as he seems to say it really needs
a good re-think.
Meanwhile, Richard Emslie, who works with me took these ideas and has
created a robust system for running this stuff in another thread.
Richard's stuff works with a package called earthenware that we're
intending to release as open source. Earthenware contains a lot of our
generic code that it really makes no sense for us to keep proprietary.
Now one thing we are doing in earthenware is creating objects which
separate the description of a GUI from its actual implementation. The
description side is not toolkit specific. This helps a lot with the two
thread problem, since the gui descriptions can be created in one thread
and implemented in the other thread + you only need to import wx in the
thread that does the implementation.
One other nice thing with this approach is you can build servers which
create the gui descriptions, pickle up the objects and send them down a
socket to a remote client which turns them into a GUI.
Currently, the only toolkit we have gui code for is wxpython + the set
of 'gui components' we have are a bit limited + some need a little
re-thinking, but the basic framework is proving powerful. We keep
threatening to look at a pygtk version, which i suspect wouldn't be huge
amounts of work.
We're planning on going to Europython in June + would be happy to meet
up with anyone interested in this stuff.
The earthenware site is here:
As yet we haven't put the code I'm describing above, we really need to
pull our fingers out and get the code out there -- will try and get some
sort of tarball out there very soon. For now all you will find is a
python package which writes gnumeric spreadsheets.