Thanks for your feedback. I ran it with --verbose-helpful, and indeed I got some helpful messages (see below). I'll have to remember that in future.
You are right, one module is loading the TKAgg backend, and the other is loading the GTK backend.
The reason I have this in my modules is that I have one module A which is intended to be very general purpose, but has a couple of hooks to do plots. Module A doesn't care which backend it uses, and at the moment it uses the matplotlib.matlab interface because that's what I knew when I wrote it.
Module B is a more specific application, which was using matlab calls, but I found I had to convert it to use GTK and the matplotlib API because I call it from application C which has a GUI window using GTK and glade.
Summary:
module A: general purpose, matlab API, no hardcoded backend
module B: more specialised, matplotlib API, GTK backend, explicit GTK window management
app C: more specialised, no matplotlib or matlab, GTK & glade GUI, functions from modules A and B used in callback threads
I don't really want to force module A to use GTK, because TKAgg (or whatever's in .matplotlibrc) is more likely to work for other users on other machines. So for the moment I can get by, if I import module A after module B.
But maybe there is some nice way to do things that I'm missing. Perhaps I can convert module A to use the matplotlib API but still not specify the backend, and it will still work standalone and also start playing nicely with module B and app C. I'll have a play with it when I get some time.
Here is the output from "python frog.py --verbose-helpful":
$ python frog.py --verbose-debug
matplotlib data path c:\Python23\share\matplotlib
loaded rc file c:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.64
verbose.level debug
interactive is False
numerix Numeric 23.3
font search path ['c:\\Python23\\share\\matplotlib', '/usr/share/fonts/msttf']
loaded ttfcache file M:\home\mra\.ttffont.cache
matplotlib data path c:\Python23\share\matplotlib
loaded rc file c:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.64
verbose.level debug
interactive is False
backend TkAgg version 8.4
Could not load matplotlib icon: Couldn't recognize the image file format for file 'c:\Python23\share\matplotlib\matplotlib.svg'
Traceback (most recent call last):
File "frog.py", line 6, in ?
embedding_in_gtk2_mra.plotme()
File "M:\home\My Documents\My Downloads\matplotlib-0.64\matplotlib-0.64\exampl es\embedding_in_gtk2_mra.py", line 43, in plotme
toolbar = NavigationToolbar(canvas, win)
File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 963, in __init__
NavigationToolbar2.__init__(self, canvas)
File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py", line 786, in __init__
self._init_toolbar()
File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1028, in _init_toolbar
self._init_toolbar2_4()
File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1091, in _init_toolbar2_4
parent=self.win,)
File "C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 1423, in __init__
self.IMAGE_FORMAT = matplotlib.backends.backend_mod.IMAGE_FORMAT
AttributeError: 'module' object has no attribute 'IMAGE_FORMAT'
Cheers,
Matthew.
John Hunter wrote:
···
"matthew" == matthew arnison <maffew@...66...> writes:
> Oh dear. I'm going to take another u-turn, and say I hit
> this IMAGE_FORMAT attribute glitch again.
Try running your script with --verbose-helpful or --verbose-debug and
report the output. That way we can see what is happening behind the
scenes.
> To atone for my reversals, I have isolated a test case,
> and I attach sample code. It seems to be triggered by
> importing matplotlib.matlab in one module, and importing
> matplotlib backend stuff directly in another module.
> Running frog.py gives:
> line 1423, in __init__ self.IMAGE_FORMAT =
> matplotlib.backends.backend_mod.IMAGE_FORMAT
> AttributeError: 'module' object has no attribute
> 'IMAGE_FORMAT'
Fernando added the backend_mod to matplotlib.backends.__init__.py --
perhaps he has some insight into what is going on.
> As commented in the code, changing the order of the
> import statements in frog.py avoids the bug. Or using the
> workaround I mentioned below.
> Hmmm. Now I remember an email from John Hunter saying
> that pythonic matplotlib should not be mixed with the
> matlab interface. Maybe this glitch is an artefact of
> that. It does mean however that all my modules have to
> use one API or the other.
Yes, this is basically undefined. When using the API, you control
figure canvases, windows, backends, etc, independently. When you
import matplotlib.matlab, it parses your rc file (or not finding it
falls back on a default) and may try and load a different backend.
Since IMAGE_FORMAT is only used in some backends, my guess is you are
seeing a backend conflict. Running --verbose-helpful should give you a
clue about which backends matplotlib is loading.
Note there are scant few features in the matlab interface that you
can't access directly from the API. There is no compelling reason to
mix them, save laziness, and as you are finding, it doesn't really
save you any time. If you want to use something from the matlab
interface and aren't sure how to do it from the API, open up matlab.py
and take a look at how that function does it. A large number if not
the majority of matlab interface functions simply forward their calls
on to the current axes.
JDH