matplotlib-devel Mailing List for matplotlib (Page 5)

"""
Demonstrates that, as of v. 1.0.0, Axes.autoscale_view always uses tight 
scaling when all children are images, regardless of the passed *tight* 
parameter.  Effectively, tight=False acts like tight=None.
"""

import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt
import matplotlib.ticker as mtick

field = np.array([[0, 1], [1, 0]])  # image data
extent = l, r, b, t = (-1.5, 1.5, -1.5, 1.5)  # Extents will lie between ticks.
tight_seq = (None, False, True)  # values of *tight* to test

# Make two rows and a column of subplots for each *tight* value.
fig, axes = plt.subplots(2, len(tight_seq))
for ax in axes.flat:                                      # In all subplots, 
    ax.imshow(field, extent=extent)                       # show the image
    ax.xaxis.set_major_locator(mtick.MultipleLocator(1))  # and set locators.
    ax.yaxis.set_major_locator(mtick.MultipleLocator(1))
for ax in axes[1]:                 # In the second row, 
    ax.plot([l, r], [b, t], 'g-')  # plot a line across the image.
for ax_row in axes:
    for (ax, tight) in zip(ax_row, tight_seq):  # Apply each *tight* value
        ax.autoscale_view(tight=tight)          # to the subplot...
        if ax.is_first_row():
            ax.set_title('tight = %s' % tight)  # and title.
plt.show()

Hello,

The MacOS X backend does not seem to show lines between cells when using pcolormesh. I have submitted a bug report:

https://sourceforge.net/tracker/?func=detail&aid=3081512&group_id=80706&atid=560720

Cheers,

Tom

On Mon, Oct 4, 2010 at 6:13 AM, Michael Droettboom <md...@st...> wrote:
> The problem is when callbacks create cyclical references (which your
> example does not).  If the Handler class in your example needed to
> update the figure or canvas in some way in the callback (which is a
> common usage pattern), that cyclical reference prevents either from
> being destroyed without running the cyclical garbage collector.  And in
> that case, you can't write a __del__ method on the handler to explicitly
> disconnect the callbacks.
>> In any case, if my logic is flawed (quite likely, since I imagine M.
>> D. had a good look at this), it might be worth adding a
>>
>> .. warning::
>>
>> section about this pattern to the event docs:
>>
>> http://matplotlib.sourceforge.net/users/event_handling.html
>>
>> because the problem is subtle and hard to diagnose (I just noticed it
>> had also been reported recently
>> http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.com&forum_name=matplotlib-devel).
>>
> True -- it's non-obvious and confusing.  On the other hand, the user is
> no longer required to explicitly disconnect callbacks, which was the
> source of many other subtle and hard to diagnose problems within the
> matplotlib code itself.
>
> I'm still not completely happy with it, so I'd love to find a "third
> way" if there's anything anyone can suggest.

Thanks for your explanation, it makes complete sense.

I think it's OK, Eric just added a warning to the docs, which will go
a long ways towards making this less of a user trap.  Given the
details you provided, I can't think of a generic way to handle these
cycles 100% automatically.  Using weakrefs seems like the most
sensible solution, and users will just need to understand a little bit
more before using this functionality.

Event handling isn't raw  beginner material in any case, so I don't
think it's a huge problem.  And if someone ever devises a clever
solution to the problem, then great!  But for now I think you can
safely ignore this further.

Regards,

f

  On 10/04/2010 09:38 AM, Benjamin Root wrote:
> On Sat, Oct 2, 2010 at 1:16 PM, 01d <ol...@gm... 
> <mailto:ol...@gm...>> wrote:
>
>
>     Are developers of matplotlib planning to implement something like
>     this:
>     http://www.pyngl.ucar.edu/Examples/Images/ngl04p.2.png ?
>     Thanks.
>
>
> That would be a nice feature to add.  Would you like to file a feature 
> request on that?
>
> http://sourceforge.net/tracker/?group_id=80706
>

Also, it seems like mathematica has a very nice streamline plot 
function, for comparison:

http://reference.wolfram.com/mathematica/ref/StreamPlot.html

Jason

  On 10/04/2010 09:38 AM, Benjamin Root wrote:
> On Sat, Oct 2, 2010 at 1:16 PM, 01d <ol...@gm... 
> <mailto:ol...@gm...>> wrote:
>
>
>     Are developers of matplotlib planning to implement something like
>     this:
>     http://www.pyngl.ucar.edu/Examples/Images/ngl04p.2.png ?
>     Thanks.
>
>
> That would be a nice feature to add.  Would you like to file a feature 
> request on that?
>
> http://sourceforge.net/tracker/?group_id=80706

I would also love to have streamlines implemented.

Note that there is a scikit that does similar things using line 
convolution integrals:

http://www.scipy.org/scipy/scikits/#vectorplot

(not streamlines, but it creates a texture which gives you the idea of 
where streamlines are).

Jason

Hi there,

I am a newcomer to this sort of thing, and inherited some Python code that
used matplotlib. I compiled the code as a windows executable, and sent it
out to my students..  Now, one of them is coming back to me with the error
you speak of.. (i.e. facefile problem with Vera.ttf)

Any hint on getting around this?

Maybe I need to give more info, however I am not sure what you might need..

Any help, gratefully accepted.



Benjamin Root-2 wrote:
> 
> Yes!  Thank you!
> 
> As extra debugging info, the issue was happening regardless of me choosing
> GTK, GTKAgg, and others for backends.
> 
> Ben Root
> 
> On Thu, Jun 3, 2010 at 2:45 PM, John Hunter <jd...@gm...> wrote:
> 
> 
>>
>> Just a shot in the dark, but does it help to flush the font cache in
>> your .matplotlib dir?
>>
>>  > rm -rf ~/.matplotlib/font*.cache
>>
>> JDH
>>
> 
> 

-- 
View this message in context: http://old.nabble.com/RuntimeError%3A-Could-not-open-facefile-tp28772066p29879230.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Sat, Oct 2, 2010 at 1:16 PM, 01d <ol...@gm...> wrote:

>
> Are developers of matplotlib planning to implement something like this:
> http://www.pyngl.ucar.edu/Examples/Images/ngl04p.2.png ?
> Thanks.
>

That would be a nice feature to add.  Would you like to file a feature
request on that?

http://sourceforge.net/tracker/?group_id=80706

Ben Root

On 10/04/2010 02:10 AM, Mitchell Jon Stanton-Cook wrote:
> Hi Andrew,
>
> Thanks for the reply.
>
> I do not want to force users of my software to have to download and
> install basemap. It's just overkill for a small Python program that I'm
> developing.
>
> Perhaps I'm best to try and use a PathPatch for the  _gen_axes_patch
> _gen_axes_spines. Does anyone have any ideas?
>    
Yes -- you would need to make a custom shape, and PathPatch or Polygon 
(if straight line segments are sufficient) are probably the way to go.

Mike
> Regards
>
> Mitch
>
>
>
> On 04/10/10 06:10, Andrew Straw wrote:
>    
>>     On 10/2/2010 8:33 PM, Mitchell Jon Stanton-Cook wrote:
>>
>>      
>>> Hello,
>>>
>>> I have been trying to modify the custom projection example
>>> (http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html)
>>> to plot a Sanson Flamsteed Projection (Sinusoidal projection).
>>>
>>>        
>> Dear Mitchell,
>>
>> Can you use the 'sinu' projection in basemap? E.g.
>> basemap/examples/contour_demo.py figure 1.
>>
>> -Andrew
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization is moving to the mainstream and overtaking non-virtualized
>> environment for deploying applications. Does it make network security
>> easier or more difficult to achieve? Read this whitepaper to separate the
>> two and get a better understanding.
>> http://p.sf.net/sfu/hp-phase2-d2d
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>      
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 10/01/2010 02:01 PM, Fernando Perez wrote:
> Hey Ryan,
>
> On Fri, Oct 1, 2010 at 6:27 AM, Ryan May<rm...@gm...>  wrote:
>    
>> On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez<fpe...@gm...>  wrote:
>>      
>>> This manifested itself in some more complex MPL code that had multiple
>>> events not working when run inside ipython, but working OK outside of
>>> ipython.  Fortunately, the small self-contained example demonstrates
>>> the problem even with ipython not being in the picture at all (the
>>> runs above were from the command line), so I think there is an issue
>>> in MPL proper.
>>>
>>> Sorry that I can't dig deeper into the code right now to look for a fix...
>>>        
>> Somewhere in the 1.0 development cycle, Michael modified the callback
>> code to take weak references to methods.  The purpose was to eliminate
>> some "leaks" that were occurring because callback connections to
>> objects were keeping them around and the proper disconnects were not
>> made (much simpler fix than tracking down every mpl_connect and trying
>> to see where do disconnect). What you're seeing in your script is that
>> since you're not assigning the Handler object to anything, it's being
>> garbage collected. It works for me if I change the second to last line
>> to:
>>
>>     h = Handler(f)
>>      
> Many thanks for the info, that helps a lot.
>
> I was wondering though, would we still have a leak if strong
> references are held in the canvas attribute?  The canvas will be
> deleted when the figure goes away, so that should properly allow the
> callback references to be deleted, without deleting them early
> otherwise, no?
>    
The problem is when callbacks create cyclical references (which your 
example does not).  If the Handler class in your example needed to 
update the figure or canvas in some way in the callback (which is a 
common usage pattern), that cyclical reference prevents either from 
being destroyed without running the cyclical garbage collector.  And in 
that case, you can't write a __del__ method on the handler to explicitly 
disconnect the callbacks.
> In any case, if my logic is flawed (quite likely, since I imagine M.
> D. had a good look at this), it might be worth adding a
>
> .. warning::
>
> section about this pattern to the event docs:
>
> http://matplotlib.sourceforge.net/users/event_handling.html
>
> because the problem is subtle and hard to diagnose (I just noticed it
> had also been reported recently
> http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.com&forum_name=matplotlib-devel).
>    
True -- it's non-obvious and confusing.  On the other hand, the user is 
no longer required to explicitly disconnect callbacks, which was the 
source of many other subtle and hard to diagnose problems within the 
matplotlib code itself.

I'm still not completely happy with it, so I'd love to find a "third 
way" if there's anything anyone can suggest.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi Andrew,

Thanks for the reply.

I do not want to force users of my software to have to download and 
install basemap. It's just overkill for a small Python program that I'm 
developing.

Perhaps I'm best to try and use a PathPatch for the  _gen_axes_patch  
_gen_axes_spines. Does anyone have any ideas?

Regards

Mitch



On 04/10/10 06:10, Andrew Straw wrote:
>    On 10/2/2010 8:33 PM, Mitchell Jon Stanton-Cook wrote:
>    
>> Hello,
>>
>> I have been trying to modify the custom projection example
>> (http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html)
>> to plot a Sanson Flamsteed Projection (Sinusoidal projection).
>>      
> Dear Mitchell,
>
> Can you use the 'sinu' projection in basemap? E.g.
> basemap/examples/contour_demo.py figure 1.
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> Virtualization is moving to the mainstream and overtaking non-virtualized
> environment for deploying applications. Does it make network security
> easier or more difficult to achieve? Read this whitepaper to separate the
> two and get a better understanding.
> http://p.sf.net/sfu/hp-phase2-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    

On 10/01/2010 03:59 PM, Stan West wrote:
> Hi, developers. I stumbled upon this when I noticed that gist_stern_r
> isn't the reverse of gist_stern. As the attached script shows, the
> discontinuity in red is wrong, and green stays zero instead of ramping.
> The problem seems to be that when cm.revcmap() reverses a linear segment
> map spec (such as {'red': [(0, 0, 0), (0.5, 1, 1), (1, 1, 1)], ...}), it
> doesn't swap the second and third elements of each tuple—the color
> values facing in each direction. That makes no difference for continuous
> colormaps but distorts discontinuous maps such as gist_stern. I believe
> that the attached "cm.patch" file fixes the problem.
>
> The other patch, "_cm.patch", is only aesthetic after the above patch is
> applied. It changes an element of the gist_stern colormap spec that
> should have been unused but which caused the green channel to stay at
> zero with the old revcmap. With the patched revcmap, the changed element
> should not be used, but the colormap spec will look like most others
> with the second and third elements of the tuple being equal.
>

Patches committed in 8725.  Thank you.

Eric

On Sun, Oct 3, 2010 at 2:05 PM, Eric Firing <ef...@ha...> wrote:
>
>> section about this pattern to the event docs:
>>
>> http://matplotlib.sourceforge.net/users/event_handling.html
>
> Done in 8723.

Thanks!

Cheers,

f

On 10/01/2010 08:01 AM, Fernando Perez wrote:

>
> In any case, if my logic is flawed (quite likely, since I imagine M.
> D. had a good look at this), it might be worth adding a
>
> .. warning::
>
> section about this pattern to the event docs:
>
> http://matplotlib.sourceforge.net/users/event_handling.html

Done in 8723.

Eric

  On 10/2/2010 8:33 PM, Mitchell Jon Stanton-Cook wrote:
> Hello,
>
> I have been trying to modify the custom projection example
> (http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html)
> to plot a Sanson Flamsteed Projection (Sinusoidal projection).

Dear Mitchell,

Can you use the 'sinu' projection in basemap? E.g. 
basemap/examples/contour_demo.py figure 1.

-Andrew

Hello,

I have been trying to modify the custom projection example 
(http://matplotlib.sourceforge.net/examples/api/custom_projection_example.html) 
to plot a Sanson Flamsteed Projection (Sinusoidal projection).

Such a projection is defined as:

long0=0
x = (long-long0)*cos(lat)
y=lat

The problem is how to correctly handle the:
* _gen_axes_patch
* _gen_axes_spines

As the resultant plot area/plot boundaries is not circular/elliptical 
like the examples provided.

Does anyone, who has played with this projections, or has better 
understanding of matplotlib provide me with a way to handle this?

Regards

Mitchell

Are developers of matplotlib planning to implement something like this:
http://www.pyngl.ucar.edu/Examples/Images/ngl04p.2.png ?
Thanks.
-- 
View this message in context: http://old.nabble.com/Streamlines-tp29867429p29867429.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

On Fri, Oct 1, 2010 at 8:59 PM, Stan West <sta...@nr...> wrote:

>  Hi, developers. I stumbled upon this when I noticed that gist_stern_r
> isn't the reverse of gist_stern. As the attached script shows, the
> discontinuity in red is wrong, and green stays zero instead of ramping. The
> problem seems to be that when cm.revcmap() reverses a linear segment map
> spec (such as {'red': [(0, 0, 0), (0.5, 1, 1), (1, 1, 1)], ...}), it doesn't
> swap the second and third elements of each tuple—the color values facing in
> each direction. That makes no difference for continuous colormaps but
> distorts discontinuous maps such as gist_stern. I believe that the attached
> "cm.patch" file fixes the problem.
>
> The other patch, "_cm.patch", is only aesthetic after the above patch is
> applied. It changes an element of the gist_stern colormap spec that should
> have been unused but which caused the green channel to stay at zero with the
> old revcmap. With the patched revcmap, the changed element should not be
> used, but the colormap spec will look like most others with the second and
> third elements of the tuple being equal.
>
>
I can confirm the bug, but I have not tested the patch.

Ben Root

import matplotlib as mpl
import matplotlib.pyplot as plt
import matplotlib.cm as mcmap
import numpy as np

def show_cmap_rgb(cmap, axes):
    x = np.linspace(0, 1, 256)
    rgba = cmap(x)
    lines = []
    for (idx, color) in enumerate('rgb'):
        lines.extend(axes.plot(x, rgba[:, idx], ':', color=color))
    axes.set_xlim(0, 1)
    axes.set_ylim(-0.1, 1.1)
    return lines

fig = plt.figure()

axes_f = fig.add_subplot(2, 1, 1)
show_cmap_rgb(mcmap.gist_stern, axes_f)
axes_f.set_title('Forward')

axes_r = fig.add_subplot(2, 1, 2)
show_cmap_rgb(mcmap.gist_stern_r, axes_r)
axes_r.invert_xaxis()
axes_r.set_title('Reversed')

On 10/01/2010 09:40 AM, Friedrich Romstedt wrote:
> There were several question on the user's list in the recent past
> reporting hangs and similar when using TkAgg backend&  interactive
> mode.
>
> It is known that Tkinter doesn't play well with threading, as long as
> one isn't done very carefully.
>
> It could be that matplotlib has implemented it in a way not safe for
> Tkinter.  This applies if there are Tkinter methods called from
> threads other than those which imported Tkinter.
>
> It results in unpredicatable behaviour with exactly the features
> reported: Hang-ups, blankening, partial hangup of part of the threads.
>
> Is a rewrite of the Tk interactive code necessary?

I don't see any use of the threading module in backend_tkagg.py or 
backend_bases.py.  Is that what you are referring to?

Ipython -pylab does use threads (version 0.10), but is intended to avoid 
problems by running all user code in a single separate thread.

Eric

>
> Friedrich

On Fri, Oct 1, 2010 at 5:07 PM, Paul Kienzle <pau...@ni...> wrote:

> Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac
> dmg.
>
> The files in mpl-data/images were not installed with read permissions
> for all.
>
> This resulted in an error that _cidgcf was not a valid attribute in
> FigureManager.
>
> This affected one 10.5 machine but not another --- we have no idea why.
>
>     - Paul
>
>
We have noticed this for a little while now, and I think we recently
narrowed down the cause.  The difference between computers might have to do
with exactly how it was installed.

Not exactly sure, but it is possible that if it was installed from an
account with admin rights, you get a different behavior than if you install
from an account without admin rights and have to give an admin password.

Was there a difference in setups for the two computers and/or how you
installed matplotlib?

Ben Root

Note a small issue on the install of matplotlib-1.0.0 python 2.6 mac  
dmg.

The files in mpl-data/images were not installed with read permissions  
for all.

This resulted in an error that _cidgcf was not a valid attribute in  
FigureManager.

This affected one 10.5 machine but not another --- we have no idea why.

     - Paul

There were several question on the user's list in the recent past
reporting hangs and similar when using TkAgg backend & interactive
mode.

It is known that Tkinter doesn't play well with threading, as long as
one isn't done very carefully.

It could be that matplotlib has implemented it in a way not safe for
Tkinter.  This applies if there are Tkinter methods called from
threads other than those which imported Tkinter.

It results in unpredicatable behaviour with exactly the features
reported: Hang-ups, blankening, partial hangup of part of the threads.

Is a rewrite of the Tk interactive code necessary?

Friedrich

Hey Ryan,

On Fri, Oct 1, 2010 at 6:27 AM, Ryan May <rm...@gm...> wrote:
> On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez <fpe...@gm...> wrote:
>> This manifested itself in some more complex MPL code that had multiple
>> events not working when run inside ipython, but working OK outside of
>> ipython.  Fortunately, the small self-contained example demonstrates
>> the problem even with ipython not being in the picture at all (the
>> runs above were from the command line), so I think there is an issue
>> in MPL proper.
>>
>> Sorry that I can't dig deeper into the code right now to look for a fix...
>
> Somewhere in the 1.0 development cycle, Michael modified the callback
> code to take weak references to methods.  The purpose was to eliminate
> some "leaks" that were occurring because callback connections to
> objects were keeping them around and the proper disconnects were not
> made (much simpler fix than tracking down every mpl_connect and trying
> to see where do disconnect). What you're seeing in your script is that
> since you're not assigning the Handler object to anything, it's being
> garbage collected. It works for me if I change the second to last line
> to:
>
>    h = Handler(f)

Many thanks for the info, that helps a lot.

I was wondering though, would we still have a leak if strong
references are held in the canvas attribute?  The canvas will be
deleted when the figure goes away, so that should properly allow the
callback references to be deleted, without deleting them early
otherwise, no?

In any case, if my logic is flawed (quite likely, since I imagine M.
D. had a good look at this), it might be worth adding a

.. warning::

section about this pattern to the event docs:

http://matplotlib.sourceforge.net/users/event_handling.html

because the problem is subtle and hard to diagnose (I just noticed it
had also been reported recently
http://sourceforge.net/mailarchive/forum.php?thread_name=4C9B7793.5020908%40gmail.com&forum_name=matplotlib-devel).

In any case, thanks again for the help!

Cheers,

f

On Fri, Oct 1, 2010 at 1:05 AM, Fernando Perez <fpe...@gm...> wrote:
> This manifested itself in some more complex MPL code that had multiple
> events not working when run inside ipython, but working OK outside of
> ipython.  Fortunately, the small self-contained example demonstrates
> the problem even with ipython not being in the picture at all (the
> runs above were from the command line), so I think there is an issue
> in MPL proper.
>
> Sorry that I can't dig deeper into the code right now to look for a fix...

Somewhere in the 1.0 development cycle, Michael modified the callback
code to take weak references to methods.  The purpose was to eliminate
some "leaks" that were occurring because callback connections to
objects were keeping them around and the proper disconnects were not
made (much simpler fix than tracking down every mpl_connect and trying
to see where do disconnect). What you're seeing in your script is that
since you're not assigning the Handler object to anything, it's being
garbage collected. It works for me if I change the second to last line
to:

    h = Handler(f)

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Howdy,

I spent a while chasing my tail today with some event handling code
until I tried backtracking from SVN matplotlib back to 0.99.1 (the one
in ubuntu 10.04) and the problem went away.

I'm attaching a script that reproduces the problem with a full
description in the docstring, reproduced here for completeness:

This example wires two event handlers that both respond to clicks by printing
event info identically.  One is written as a standalone function, the other as
a method of an object.

- when run with MPL 0.99.1.1 (stock in ubuntu 10.04), both fire fine:

amirbar[mplbrush]> python mpleventbug.py
MPL version: 0.99.1.1
MPL: /usr/lib/pymodules/python2.6/matplotlib/__init__.py
/usr/lib/pymodules/python2.6/matplotlib/backends/backend_gtk.py:621:
DeprecationWarning: Use the new widget gtk.Tooltip
  self.tooltips = gtk.Tooltips()
C1 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C2 - button=1, x=146, y=229, xdata=23.783488, ydata=0.846491
C1 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C2 - button=1, x=216, y=189, xdata=42.919628, ydata=0.671053
C1 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
C2 - button=1, x=288, y=117, xdata=62.602515, ydata=0.355263
etc...

- when run with matplotlib r8721, the one that is a method does not fire:

amirbar[mplbrush]> python mpleventbug.py
MPL version: 1.0.0
MPL: /home/fperez/usr/opt/lib/python2.6/site-packages/matplotlib/__init__.pyc
C1 - button=1, x=150, y=170, xdata=24.876982, ydata=0.587719
C1 - button=1, x=169, y=160, xdata=30.071077, ydata=0.543860
C1 - button=1, x=187, y=135, xdata=34.991799, ydata=0.434211
C1 - button=1, x=210, y=120, xdata=41.279388, ydata=0.368421


###

This manifested itself in some more complex MPL code that had multiple
events not working when run inside ipython, but working OK outside of
ipython.  Fortunately, the small self-contained example demonstrates
the problem even with ipython not being in the picture at all (the
runs above were from the command line), so I think there is an issue
in MPL proper.

Sorry that I can't dig deeper into the code right now to look for a fix...

Timing note: EPD is planning a release in a few weeks, I don't know
how close MPL is to a bugfix release in the 1.0.x series.  I don't
know what version of mpl EPD plans to use, but if event handling is
really broken and a fix is feasible in the time available, it might be
worth pushing it through.

Cheers,

f