Re: [Matplotlib-users] minor gtk issues with 0.64

[matthew a. <ma...@ca...>]

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 <ma...@ca...> writes:
> 
> 
>     matthew> Oh dear. I'm going to take another u-turn, and say I hit
>     matthew> 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.
> 
>     matthew> To atone for my reversals, I have isolated a test case,
>     matthew> and I attach sample code. It seems to be triggered by
>     matthew> importing matplotlib.matlab in one module, and importing
>     matthew> matplotlib backend stuff directly in another module.
> 
>     matthew> Running frog.py gives:
>     matthew> line 1423, in __init__ self.IMAGE_FORMAT =
>     matthew> matplotlib.backends.backend_mod.IMAGE_FORMAT
>     matthew> AttributeError: 'module' object has no attribute
>     matthew> 'IMAGE_FORMAT'
> 
> Fernando added the backend_mod to matplotlib.backends.__init__.py --
> perhaps he has some insight into what is going on.
> 
>     matthew> As commented in the code, changing the order of the
>     matthew> import statements in frog.py avoids the bug. Or using the
>     matthew> workaround I mentioned below.
> 
>     matthew> Hmmm. Now I remember an email from John Hunter saying
>     matthew> that pythonic matplotlib should not be mixed with the
>     matthew> matlab interface. Maybe this glitch is an artefact of
>     matthew> that. It does mean however that all my modules have to
>     matthew> 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