Development matplotlib-devel
1

Hello Kirill,

I'm the WX maintainer for Matplotlib, so hopefully can cover a couple of your issues with WX.

WX/WXAgg -- both don't work from console -- show empty window, cursor
turns in hourglass when it is over plot window. From GUI app
(IDLE/PythonWin) it seems to work at first glance -- plot gets created,
but the plot window can not be closed with either Alt-F4 or mouse. It
just does not react on close command. Moreover, python objects
corresponding to window seems to get destroyed when I try to close
window, because if I do few plots commands without trying to close the
window, new plots appear in first window, however as soon as I try to
close the window (it won't close, remember?), new plots will open new
window. That second window can be closed, but first one still remain
unclosable.

I'm assuming that you're running from the console in the recommended way (i.e pythonw file.py -dWX).

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.

I tend to prefer to use the PyCrust console for Wx (it's part of the Wx distribution)

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.

Any ideas how that can be fixed, work arounded, debugged? I am pretty
comfortable with debugging Python code, but as I said I don't have C
compiler yet, so can't debug extensions.

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.

Good luck

Jeremy

2

Jeremy,

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 *
>>> plot((1,2,3))

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.

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.

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.

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?

Thanks,
Kirill.

3

Jeremy,

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 *
>>> plot((1,2,3))

You probably want.

import matplotlib
matplotlib.interactive(True)
matplotlib.use('WX')
from matplotlib.matlab import *
plot([1,2,3])

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

import matplotlib
matplotlib.interactive(True)
matplotlib.use('WX')
from matplotlib.matlab import *
plot([1,2,3])
...

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.

Regards

Jeremy

ยทยทยท

On 8 Jun 2004, at 13:51, Kirill Lapshin wrote:

4

Jeremy,

    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 *
    >>> plot((1,2,3))

You probably want.

import matplotlib
matplotlib.interactive(True)
matplotlib.use('WX')
from matplotlib.matlab import *
plot([1,2,3])

What I forgot to mention is that I changed .matplotlibrc to use WX and interactive mode. In fact, all tests I did were performed the same way -- change .matplotlibrc to choose backend and set interactive to True or False, then open python from console try import/plot, open pythonwin try import/plot. I presume there is no difference between setting backend/interactivity via .matplotlibrc or via explicit calls to matplotlib api.

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.

Yeah, quite a lot of different options to test, a lot of platforms, not to mention that testing GUI is hard by itself. World would be so much better if one could easily unittest GUIs.

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).

Oh, so that's yet another way to switch backends? Good to know.

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 see. I guess I have to find a combination of satisfactory IDE / matplotlib backend. From what I see now, Boa is pretty much the last resort for windows.

BTW, does anyone know what the situation is with various IDE / matplotlib backends compatibility on Linux? Particularly I am curious to know if there is a way to use matplotlib from Eric3, which is a QT based app.

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.

I see your point, the only reason I asked about automatic backend selection is because I may want to use matplotlib from different tools, say an IDE, xemacs, ipython, and it might be that they will require different backends, so I'll have to select one manually every time which is quite annoying. I guess we'll have to cope with it for now, hoping that one day you'll put GUI into a separate thread and it will resolve all issues.

BTW, how about plotting from separate process? Pickle data, send via some interprocess communication or even temporary file to plotting process. This should not be too hard to implement, right? It might be yet another backend.

--Kirill