Thanks for fast response.
I'm assuming that you're running from the console in the recommended way (i.e pythonw file.py -dWX).
Not really. I am mostly interested in interactive usage, hence I am simply firing python or ipython from console, and then in python shell issuing couple of commands like:
>>> from matplotlib.matlab import *
You probably want.
from matplotlib.matlab import *
See the explanation a bit further down.
I am not surprised that you are having problems running the Wx backend from Idle and/or PythonWin. It is generally problematic to launch a GUI app from an application which uses a different GUI backend (e.g a Wx app from Idle (which is Tk)) as the event loops get in each others' way. There are a few things I have to fix in the window close code for Wx anyway (it's broken in some respects) - for the moment the recommended way is to use the 'close window' button.
Oh, I see. That explains it. I tried it from PyCrust and it does work much better, though still there are some rough edges. Interactive mode works, which is the most important one for me, but non-interactive does not return back to python prompt after show() command, also cursor turns into hourglasses when it is over plot window. Looks like there are still some problems with message loop.
There are a couple of issues I keep meaning to get around to fixing. One problem is that I don't really use interactive mode, so I don't notice things so much in that area (not that this is an excuse...). The key difficulty is that the mainloop behaves subtly differently when running interactively and from a script. Every time I make one work correctly, it seems to break the other in unpredictable ways.
However, I'm quite concerned that launching from the Windows console causes problems. It should work correctly, provided that python is on the path and WxPython is installed correctly in site-lib.
Yes, python is on the path, wxPython installed correctly in site-packages. So what is the deal with "recommended way" of running from console? pythonw will detach from console, but what -dWX do? It is passed as an argument to script, so looks like it is responsibility of the script to use it. Does that mean that WX backend can not be used from regular console python shell? That would be quite unfortunate, because for example IPython only runs interactively on console.
The -dWX option tells matplotlib to use the Wx renderer to run the script. You can also set the preferred default renderer in the matplotlibrc file. As installed, I think this defaults to GtkAgg, but you can change it (see http://matplotlib.sourceforge.net/.matplotlibrc).
Your other option is to follow (http://matplotlib.sourceforge.net/interactive.html) and do
from matplotlib.matlab import *
This has the effect of hard-wiring the backend before importing the remainder of the matplotlib symbols.
I'd recommend boa-constructor (http://boa-constructor.sourceforge.net) for debugging Wx code. It's a pretty decent IDE, contains the best debugger I've yet found for Python, and is based on the Wx toolkit, so doesn't have the event loop issue mentioned above.
Last time I checked Boa, it was quite buggy. Maybe it is time to give it a second try. Thanks for the pointer.
Boa is quite buggy in places, and imposes its own way of working with Wx that doesn't suit me (at least for larger projects). However, the debugger is worth the effort.
I am hoping someone familiar with TkAgg backend will step out and help with Tk problems.
BTW, since decision which backend to use depends quite a lot on program you are running matplotlib from, would it be possible to autodetect host program and choose appropriate backend?
We've looked at different ways to deal with the mainloop problem, but it is difficult to find a portable approach. It would probably be quite straightforward to look at sys.argv and issue a different matplotlib.use() call from there. Not sure that this would be easy to generalise (as there are so many possible shells).
In the longer term, John Hunter has been looking at putting the GUI into a separate thread, to avoid mainloop problems. A partial solution exists within scipy for this, but only applies, if memory serves, to Wx only, whereas we would need a solution for all backends. We're aware that this is quite annoying, although to be honest I think that most people use only one backend with their preferred tools.
On 8 Jun 2004, at 13:51, Kirill Lapshin wrote: