matplotlib-devel Mailing List for matplotlib

The patch is now applied to the SVN (r6479).
-JJ
On Tue, Dec 2, 2008 at 5:03 PM, Darren Dale <dsd...@gm...> wrote:
> This looks right to me, thank you Jae-Joon.
>
>
> On Tue, Dec 2, 2008 at 4:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
>>
>> Darren,
>>
>> Can you test the attached patch and see if the legend is placed where
>> you expected.
>> Regards,
>>
>> -JJ
>
>

Darren,
Can you test the attached patch and see if the legend is placed where
you expected.
Regards,
-JJ

I presume my changes currently only allow loc as a location code.
I didn't know that loc can be a tuple (axes coordinate I guess?).
But it won't be hard to fix this. I'll work on it.
-JJ
On Tue, Dec 2, 2008 at 4:04 PM, Darren Dale <dsd...@gm...> wrote:
> I think something broke with the recent changes to legend. For example, in
> ipython -pylab:
>
> plot([1,2,3,4],label='test')
> legend(loc=(.1, .5))
>
> ERROR: An unexpected error occurred while tokenizing input
> The following traceback may be corrupted or invalid
> The error message is: ('EOF in multi-line statement', (185, 0))
>
> ERROR: An unexpected error occurred while tokenizing input
> The following traceback may be corrupted or invalid
> The error message is: ('EOF in multi-line statement', (46, 0))
>
> ---------------------------------------------------------------------------
> AssertionError Traceback (most recent call last)
>
> /home/darren/<ipython console> in <module>()
>
> /usr/lib64/python2.6/site-packages/matplotlib/pyplot.pyc in legend(*args,
> **kwargs)
>
> 2441
> 2442 ret = gca().legend(*args,
> **kwargs)
> -> 2443
> draw_if_interactive()
> 2444 return
> ret
> 2445 if Axes.legend.__doc__ is not
> None:
>
> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_qt4.pyc in
> draw_if_interactive()
> 38 figManager =
> Gcf.get_active()
> 39 if figManager !=
> None:
> ---> 40
> figManager.canvas.draw()
>
> 41
> 42 def
> _create_qApp():
>
> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_qt4agg.pyc in
> draw(self)
> 131 if DEBUG: print "FigureCanvasQtAgg.draw",
> self
> 132 self.replot =
> True
> --> 133
> FigureCanvasAgg.draw(self)
> 134
> self.update()
> 135 # Added following line to improve realtime pan/zoom on
> windows:
>
>
> /usr/lib64/python2.6/site-packages/matplotlib/backends/backend_agg.pyc in
> draw(self)
>
> 281
> 282 self.renderer =
> self.get_renderer()
> --> 283
> self.figure.draw(self.renderer)
>
> 284
> 285 def
> get_renderer(self):
>
> /usr/lib64/python2.6/site-packages/matplotlib/figure.pyc in draw(self,
> renderer)
>
> 770
> 771 # render the
> axes
>
> --> 772 for a in self.axes: a.draw(renderer)
> 773
> 774 # render the figure text
>
>
> /usr/lib64/python2.6/site-packages/matplotlib/axes.pyc in draw(self,
> renderer,
> inframe)
>
> 1599
> 1600 for zorder, i, a in
> dsu:
> -> 1601
> a.draw(renderer)
>
> 1602
> 1603
> renderer.close_group('axes')
>
> /usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in draw(self,
> renderer)
> 317 if
> self._drawFrame:
> 318 # update the location and size of the
> legend
>
> --> 319 bbox = self._legend_box.get_window_extent(renderer)
> 320 self.legendPatch.set_bounds(bbox.x0, bbox.y0,
> 321 bbox.width, bbox.height)
>
> /usr/lib64/python2.6/site-packages/matplotlib/offsetbox.pyc in
> get_window_extent(self, renderer)
> 196 '''
> 197 w, h, xd, yd, offsets = self.get_extent_offsets(renderer)
> --> 198 px, py = self.get_offset(w, h, xd, yd)
> 199 return mtransforms.Bbox.from_bounds(px-xd, py-yd, w, h)
> 200
>
> /usr/lib64/python2.6/site-packages/matplotlib/offsetbox.pyc in
> get_offset(self,width, height, xdescent, ydescent)
> 155 """
> 156 if callable(self._offset):
> --> 157 return self._offset(width, height, xdescent, ydescent)
> 158 else:
> 159 return self._offset
>
> /usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in
> _findoffset_loc(self, width, height, xdescent, ydescent)
> 292 "Heper function to locate the legend"
> 293 bbox = Bbox.from_bounds(0, 0, width, height)
> --> 294 x, y = self._get_anchored_bbox(self._loc, bbox,
> self.parent.bbox)
> 295 return x+xdescent, y+ydescent
> 296
>
> /usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in
> _get_anchored_bbox(self, loc, bbox, parentbbox)
> 623 display coordinates.
> 624 """
> --> 625 assert loc in range(1,11) # called only internally
> 626
> 627 BEST, UR, UL, LL, LR, R, CL, CR, LC, UC, C = range(11)
>
> AssertionError:
>
>

I think something broke with the recent changes to legend. For example, in
ipython -pylab:
plot([1,2,3,4],label='test')
legend(loc=(.1, .5))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (185, 0))
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (46, 0))
---------------------------------------------------------------------------
AssertionError Traceback (most recent call last)
/home/darren/<ipython console> in <module>()
/usr/lib64/python2.6/site-packages/matplotlib/pyplot.pyc in legend(*args,
**kwargs)
2441
 2442 ret = gca().legend(*args,
**kwargs)
-> 2443
draw_if_interactive()
 2444 return
ret
 2445 if Axes.legend.__doc__ is not
None:
/usr/lib64/python2.6/site-packages/matplotlib/backends/backend_qt4.pyc in
draw_if_interactive()
 38 figManager =
Gcf.get_active()
 39 if figManager !=
None:
---> 40
figManager.canvas.draw()
41
 42 def
_create_qApp():
/usr/lib64/python2.6/site-packages/matplotlib/backends/backend_qt4agg.pyc in
draw(self)
 131 if DEBUG: print "FigureCanvasQtAgg.draw",
self
 132 self.replot =
True
--> 133
FigureCanvasAgg.draw(self)
 134
self.update()
 135 # Added following line to improve realtime pan/zoom on
windows:
/usr/lib64/python2.6/site-packages/matplotlib/backends/backend_agg.pyc in
draw(self)
281
 282 self.renderer =
self.get_renderer()
--> 283
self.figure.draw(self.renderer)
284
 285 def
get_renderer(self):
/usr/lib64/python2.6/site-packages/matplotlib/figure.pyc in draw(self,
renderer)
770
 771 # render the
axes
--> 772 for a in self.axes: a.draw(renderer)
 773
 774 # render the figure text
/usr/lib64/python2.6/site-packages/matplotlib/axes.pyc in draw(self,
renderer,
inframe)
1599
 1600 for zorder, i, a in
dsu:
-> 1601
a.draw(renderer)
1602
 1603
renderer.close_group('axes')
/usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in draw(self,
renderer)
 317 if
self._drawFrame:
 318 # update the location and size of the
legend
--> 319 bbox = self._legend_box.get_window_extent(renderer)
 320 self.legendPatch.set_bounds(bbox.x0, bbox.y0,
 321 bbox.width, bbox.height)
/usr/lib64/python2.6/site-packages/matplotlib/offsetbox.pyc in
get_window_extent(self, renderer)
 196 '''
 197 w, h, xd, yd, offsets = self.get_extent_offsets(renderer)
--> 198 px, py = self.get_offset(w, h, xd, yd)
 199 return mtransforms.Bbox.from_bounds(px-xd, py-yd, w, h)
 200
/usr/lib64/python2.6/site-packages/matplotlib/offsetbox.pyc in
get_offset(self,width, height, xdescent, ydescent)
 155 """
 156 if callable(self._offset):
--> 157 return self._offset(width, height, xdescent, ydescent)
 158 else:
 159 return self._offset
/usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in
_findoffset_loc(self, width, height, xdescent, ydescent)
 292 "Heper function to locate the legend"
 293 bbox = Bbox.from_bounds(0, 0, width, height)
--> 294 x, y = self._get_anchored_bbox(self._loc, bbox,
self.parent.bbox)
 295 return x+xdescent, y+ydescent
 296
/usr/lib64/python2.6/site-packages/matplotlib/legend.pyc in
_get_anchored_bbox(self, loc, bbox, parentbbox)
 623 display coordinates.
 624 """
--> 625 assert loc in range(1,11) # called only internally
 626
 627 BEST, UR, UL, LL, LR, R, CL, CR, LC, UC, C = range(11)
AssertionError:

Eric Firing wrote:
> Michael Droettboom wrote:
>> Sorry -- I neglected to commit some changes. (Playing around with 
>> bzr and still getting used to it, I guess.)
>
> Very good, thank you!
Phew! For a minute there I thought I was going crazy...
>
> OT: I'm glad you are taking a look at bzr; personally, I chose hg 
> quite some time ago (when bzr was not mature enough to use), and I 
> have no regrets. It is very small, quick, and uncluttered--a 
> beautiful piece of work. (The code base is *much* smaller than bzr--I 
> like that.) The one area in which hg is a bit behind now is svn 
> interoperability,
> http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion,
> which doesn't matter at all for the uses to which I put it. Possibly 
> it will catch up soon: 
> http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion
> http://blog.red-bean.com/sussman/?p=116
Yeah -- didn't mean to start another thread about distributed version 
control -- I'm just playing with the stuff. But that was my assessment, 
too. Couldn't figure out how to use hg with a svn-based project 
(matplotlib) -- bzr was easier but still taking some getting used to. 
git has related features too I might look at.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Sorry -- I neglected to commit some changes. (Playing around with bzr 
> and still getting used to it, I guess.)
Very good, thank you!
OT: I'm glad you are taking a look at bzr; personally, I chose hg quite 
some time ago (when bzr was not mature enough to use), and I have no 
regrets. It is very small, quick, and uncluttered--a beautiful piece of 
work. (The code base is *much* smaller than bzr--I like that.) The one 
area in which hg is a bit behind now is svn interoperability,
http://www.selenic.com/mercurial/wiki/index.cgi/WorkingWithSubversion,
which doesn't matter at all for the uses to which I put it. Possibly it 
will catch up soon: 
http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion
http://blog.red-bean.com/sussman/?p=116
Eric
> 
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> Hmm... works fine for me here, both with the zoom/pan tool and zoom 
>>> to rect. Can you describe a particular action that isn't working? 
>>> I'm at a loss otherwise...
>>
>> Mike,
>>
>> When I run João's commands in ipython -pylab and click the pan/zoom 
>> button, panning or zooming moves the plotted curve, but the axvline 
>> stays in the middle of the picture instead of moving with the x=0.5 
>> point. Same with zoom-to-rect: the axvline stays in the middle of the 
>> window, not at x=0.5.
>>
>> Eric
>>
>>>
>>> Mike
>>>
>>> Eric Firing wrote:
>>>> Michael Droettboom wrote:
>>>>> Thanks for the reminder. It wasn't propagating the "non-affine" 
>>>>> invalidation correctly. I think I have a fix in r6465, but please 
>>>>> let me know if you see anything else funny.
>>>>>
>>>>> Cheers,
>>>>> Mike
>>>>
>>>> Mike,
>>>>
>>>> It looks like that helps, fixing the window resize behavior, but 
>>>> zooming and panning still do not work in the original example given 
>>>> by João Silva:
>>>>
>>>> import matplotlib.pyplot as pl
>>>> import numpy as np
>>>>
>>>> x = np.linspace(0.0,1.0,100)
>>>>
>>>> pl.semilogy(x,x**2)
>>>> pl.axvline(x=0.5,ls='--',color='k')
>>>> pl.show()
>>>>
>>>> Eric
>>>
>>
> 

Sorry -- I neglected to commit some changes. (Playing around with bzr 
and still getting used to it, I guess.)
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Hmm... works fine for me here, both with the zoom/pan tool and zoom 
>> to rect. Can you describe a particular action that isn't working? 
>> I'm at a loss otherwise...
>
> Mike,
>
> When I run João's commands in ipython -pylab and click the pan/zoom 
> button, panning or zooming moves the plotted curve, but the axvline 
> stays in the middle of the picture instead of moving with the x=0.5 
> point. Same with zoom-to-rect: the axvline stays in the middle of the 
> window, not at x=0.5.
>
> Eric
>
>>
>> Mike
>>
>> Eric Firing wrote:
>>> Michael Droettboom wrote:
>>>> Thanks for the reminder. It wasn't propagating the "non-affine" 
>>>> invalidation correctly. I think I have a fix in r6465, but please 
>>>> let me know if you see anything else funny.
>>>>
>>>> Cheers,
>>>> Mike
>>>
>>> Mike,
>>>
>>> It looks like that helps, fixing the window resize behavior, but 
>>> zooming and panning still do not work in the original example given 
>>> by João Silva:
>>>
>>> import matplotlib.pyplot as pl
>>> import numpy as np
>>>
>>> x = np.linspace(0.0,1.0,100)
>>>
>>> pl.semilogy(x,x**2)
>>> pl.axvline(x=0.5,ls='--',color='k')
>>> pl.show()
>>>
>>> Eric
>>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Hmm... works fine for me here, both with the zoom/pan tool and zoom to 
> rect. Can you describe a particular action that isn't working? I'm at 
> a loss otherwise...
Mike,
When I run João's commands in ipython -pylab and click the pan/zoom 
button, panning or zooming moves the plotted curve, but the axvline 
stays in the middle of the picture instead of moving with the x=0.5 
point. Same with zoom-to-rect: the axvline stays in the middle of the 
window, not at x=0.5.
Eric
> 
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>>> Thanks for the reminder. It wasn't propagating the "non-affine" 
>>> invalidation correctly. I think I have a fix in r6465, but please 
>>> let me know if you see anything else funny.
>>>
>>> Cheers,
>>> Mike
>>
>> Mike,
>>
>> It looks like that helps, fixing the window resize behavior, but 
>> zooming and panning still do not work in the original example given by 
>> João Silva:
>>
>> import matplotlib.pyplot as pl
>> import numpy as np
>>
>> x = np.linspace(0.0,1.0,100)
>>
>> pl.semilogy(x,x**2)
>> pl.axvline(x=0.5,ls='--',color='k')
>> pl.show()
>>
>> Eric
> 

On Tue, Dec 2, 2008 at 10:41 AM, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 2, 2008 at 8:34 AM, Gregor Thalhammer
> <gre...@gm...> wrote:
>
> > If a mouse button is pressed while leaving the figure the behaviour is
> > somewhat strange. First, a figure_leave_event is emitted. Then, further
> > moving the mouse outside the figure a new figure_enter_event is created.
> > This is the case since all mouse events, also movements outside the
> window,
> > are captured as long as a mouse button is pressed. This is a very
> convenient
> > behaviour for panning/zooming. However, when finally releasing the mouse
> > button no figure_leave_event is triggered. With the GTK backend such an
> > event is created.
> > So what should be the desired behaviour?
>
> Ahh, I hadn't considered this problem. It arises because I am using
> mpl location events to trigger the figure enter event. The solution
> is to use the gui event for the figure enter event too -- basically
> the gui needs to call the canvas.enter_notify_event. I added your
> patch and modified gtk to handle the enter_notify_event in svn r6468.
> Can you update, repatch wx to use it (and Darren qt)?
This is done for qt and qt4. In qt, if you hold the button, leave the
figure, enter the second figure, and release the button, the old figure
receives the leave event, but the new figure does not receive the enter
event. This seems like an issue with qt3, the new figure does receive the
enter event with qt4.
I noticed that if one moves the cursor rapidly through the figure and axes,
some events are not captured. For example, the cursor is in an axes but the
last event the axes received was a leave event. I'm not sure how that could
be improved, do you see it as well?
Finally, off topic, I committed the improved version checking in
mpl.__init__, using subprocess instead of popen*, which were deprecated in
python-2.6. This has been tested on two separate windows machines, hopefully
there are no lurking issues. But its something to keep in mind when we cut
the next release for windows.
Darren

On Tue, Dec 2, 2008 at 8:34 AM, Gregor Thalhammer
<gre...@gm...> wrote:
> If a mouse button is pressed while leaving the figure the behaviour is
> somewhat strange. First, a figure_leave_event is emitted. Then, further
> moving the mouse outside the figure a new figure_enter_event is created.
> This is the case since all mouse events, also movements outside the window,
> are captured as long as a mouse button is pressed. This is a very convenient
> behaviour for panning/zooming. However, when finally releasing the mouse
> button no figure_leave_event is triggered. With the GTK backend such an
> event is created.
> So what should be the desired behaviour?
Ahh, I hadn't considered this problem. It arises because I am using
mpl location events to trigger the figure enter event. The solution
is to use the gui event for the figure enter event too -- basically
the gui needs to call the canvas.enter_notify_event. I added your
patch and modified gtk to handle the enter_notify_event in svn r6468.
Can you update, repatch wx to use it (and Darren qt)?
Any takers out their to add support to tk?
Thanks,
JDH

John Hunter schrieb:
> I recently added support for a figure/axes enter/leave event. The
> figure enter and axes enter/leave are easy to do with nothing new in
> the backends, just using the native mpl events. The figure leave
> event is harder, because when a user leaves a figure and activates
> another window, mpl gets no events.
>
> To correct this, I added a leave_notify_event method to
> backend_bases.FigureCanvasBase (note this is not an mpl Event) but
> when called it will trigger a callback to those registered to the
> figure_leave_event with the last event that occurred in the window.
>
> I added support for this in gtk by connecting the the gtk signal
> 'leave_notify_event' to the mpl backend method leave_notify_event. If
> you know something about tk, wx or qt event handling, could you add a
> similar method to the appropriate backend? You can follow the example
> in backend_gtk.
>
>
> You can test with examples/event_handling/figure_axes_enter_leave.py
>
> Thanks,
> JDH
I attached a patch for the wx backend. Nearly everything has already 
been implemented. Instead of the new 'leave_notify_event' leaving the 
figure triggered a fake motion_event. I changed this.
If a mouse button is pressed while leaving the figure the behaviour is 
somewhat strange. First, a figure_leave_event is emitted. Then, further 
moving the mouse outside the figure a new figure_enter_event is created. 
This is the case since all mouse events, also movements outside the 
window, are captured as long as a mouse button is pressed. This is a 
very convenient behaviour for panning/zooming. However, when finally 
releasing the mouse button no figure_leave_event is triggered. With the 
GTK backend such an event is created.
So what should be the desired behaviour?
Gregor

Hmm... works fine for me here, both with the zoom/pan tool and zoom to 
rect. Can you describe a particular action that isn't working? I'm at 
a loss otherwise...
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Thanks for the reminder. It wasn't propagating the "non-affine" 
>> invalidation correctly. I think I have a fix in r6465, but please 
>> let me know if you see anything else funny.
>>
>> Cheers,
>> Mike
>
> Mike,
>
> It looks like that helps, fixing the window resize behavior, but 
> zooming and panning still do not work in the original example given by 
> João Silva:
>
> import matplotlib.pyplot as pl
> import numpy as np
>
> x = np.linspace(0.0,1.0,100)
>
> pl.semilogy(x,x**2)
> pl.axvline(x=0.5,ls='--',color='k')
> pl.show()
>
> Eric
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Dec 1, 2008 at 6:00 PM, Jae-Joon Lee <lee...@gm...> wrote:
> As implementing an optional transformation should be trivial, I'll
> just go ahead an work on it. But it seems not clear to me how to
> approach this without any specific use case given.
In another thread yesterday, someone was asking about a general way to
create a shadow effect. It occurred to me that we could probably use
the offsetbox for this. One could create an offset box for a given
artist that draws the artist offset from the original by 5 points or 5
pixels, in a gray color that creates the appearance of a shadow.
Would this be a reasonable use case to test the offset transformation
in either points or pixels?
JDH

Michael Droettboom wrote:
> Thanks for the reminder. It wasn't propagating the "non-affine" 
> invalidation correctly. I think I have a fix in r6465, but please let 
> me know if you see anything else funny.
> 
> Cheers,
> Mike
Mike,
It looks like that helps, fixing the window resize behavior, but zooming 
and panning still do not work in the original example given by João Silva:
import matplotlib.pyplot as pl
import numpy as np
x = np.linspace(0.0,1.0,100)
pl.semilogy(x,x**2)
pl.axvline(x=0.5,ls='--',color='k')
pl.show()
Eric

Thanks John,
I'll work on the revisions.
>
> + def set_offset(self, xy):
> + """
> + set offset of the container.
> +
> + Accept : tuple of x,y cooridnate in display units.
>
> Is it worthwhile to allow other coordinate systems for the offsets
> (points, data) or would this complicate the code with little benefit?
> On a quick read-thru, it looks like we would just need to supply an
> optional transform arg and transform the offset if necessary, so the
> implementation would be pretty clean. I see that offset can be
> callable -- is this the mechanism you intended to handle this case?
>
My original intention with the OffsetBox was to only support the
translation in the display coordinates. VPacker and HPacker even
doesn't use the transformation explicitly. One of the reason for this
was that the size of the Text objects does not depends on the
transformation. I guess in most cases, children will have a fixed
offset relative to their parent container. Introducing an arbitrary
transformation between the child and the parent may make things
complicated. On the other hand, the top most container may have its
own transformation. In the use case I considered (legend), the size of
the box is only known at the drawing time and the offset of the box
needs to be calculated on the fly (e.g., using the size of the box and
the anchor point). The reason that the offset can be a callable object
is to support such situation.
As implementing an optional transformation should be trivial, I'll
just go ahead an work on it. But it seems not clear to me how to
approach this without any specific use case given.
>
> +ax1.plot([1], label="multi\nline")
>
> For multi-line|, it appears that we are getting the default "baseline"
> vertical alignment but for the legend, 'center' would probably be more
> appropriate. Any idea how to get that to work?
>
We may do it by adjusting the baseline of the multi-line text. In the
current implementation, the baseline of the multi-line text is set to
the baseline of the first line. It may not give the perfect
center-align, but will give a reasonable results. The other way is to
treat the multiline text separately during the packing. But this will
need more work as the current Packer class does not know whether its
child is multi-line text or not. I'll see what I can do.
Regards,
-JJ