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 wxPython gui’s.
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: http://www.earthenware-services.org/earthenwarewiki/.
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.