new embedding_in_wx3 example

Hi All, I've added a new example, embedding_in_wx3, to

    > CVS. From the docstring:

Coincidentally, I was also working on a different embedding_in_wx3
which shows how to use a custom toolbar, in response to another
question off list. I changed the name submitted that as
embedding_in_wx4 :slight_smile:

    > John+Perry+whoever: the only matplotlib bug I found this
    > time is worked around by the line

    >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
    >> problem -ADS

    > We should fix that at some point.

What was the bug? I didn't notice any problems with lower.

BTW, the recommended way to set rc params in now with the rc command.
This was initially defined in matplotlib.matlab but I just moved it to
matplotlib.__init__.py to make it accessible to application
developers. You can do

  matplotlib.rc('image', origin='lower')

and set multiple image params with multiple kwargs.

        self.toolbar.update() # Not sure why this is needed - ADS

This updates the Axes menu on the toolbar, which is needed if the
number of axes have changed. Since the number of axes/subplots can
change after the figure/toolbar was created, this tells the toolbar to
update it's axes menu.

Another comment: try not to use x.resize in matplotlib examples,
because of the Numeric bug (did you get the emails Todd and I
exchanged regarding this?). Numeric segfaulted for me when I
initially ran your example with the .resize command.

Note that matplotlib.mlab has the meshgrid command for building mesh
arrays from 2 1D vectors. I replaced your code with

        x = numerix.arange(120.0)*2*numerix.pi/60.0
        y = numerix.arange(100.0)*2*numerix.pi/50.0
        self.x, self.y = meshgrid(x, y)
        z = numerix.sin(self.x) + numerix.cos(self.y)

Finally, there seems to be a figure size problem on linux: when I run
your example the figure window is too small and the image wraps.

Updates are in CVS - thanks for the submission.

JDH

John Hunter wrote:

   > John+Perry+whoever: the only matplotlib bug I found this
   > time is worked around by the line

   >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
   >> problem -ADS

   > We should fix that at some point.

What was the bug? I didn't notice any problems with lower.

Try vertically zooming and panning with the matplotlib toolbar -- you'll see that the overlay points move opposite from the data. Maybe it's my head that's on wrong, though. :slight_smile:

Updates are in CVS - thanks for the submission.

Thanks for the suggestions. You'll make a respectable (matplotlib) programmer out of me yet!

Cheers!
Andrew

John Hunter wrote:

   > John+Perry+whoever: the only matplotlib bug I found this
   > time is worked around by the line

   >> rcParams['image.origin'] = 'upper' # 'lower': nav toolbar
   >> problem -ADS

   > We should fix that at some point.

What was the bug? I didn't notice any problems with lower.

OK, I discovered a rather easy demonstration of what looks to be a (possibly the same) bug (adding 'ylim' to the image_origin demo):

from matplotlib.matlab import *

x = arange(100.0); x.shape = 10,10

subplot(211)
title('blue should be up')
imshow(x, origin='upper', interpolation='nearest')
set(gca(),'ylim',(0,23))

subplot(212)
title('blue should be down')
imshow(x, origin='lower', interpolation='nearest')
set(gca(),'ylim',(0,23))

#savefig('image_origin2')
show()