Paul Smith wrote:
I'm plotting two curves in one subplot with twinx to allow different y scales. The script below is an example. When zooming in using zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my backend) I think the x axis part of the zoom is happening twice. Rubberbanding the example from x=20 to 80 results in a zoomed x range of about 32 to 68, which is about what you'd expect for zooming with the same range twice.
Is there a way of restricting this to only one zoom?
Paul
------------
from pylab import *
f=figure(1)
ax1=f.add_subplot(111)
ax1.plot(arange(100))
ax2=twinx(ax1)
ax2.plot(-arange(100),'g')
draw()
Hi,
there was the above mail on the users list.
The problem is that "release_zoom" in backend_bases.py is called twice in the above case if zoomed to a twinx'ed plot. One way to fix this behavior is to set a "twin" attribute to the axes instance. Attached is a patch against the 0.91 trunk.
John: is this okay or is there a better way to fix the problem?
Manuel
twinzoom.patch (1.78 KB)
Manuel Metz wrote:
Paul Smith wrote:
I'm plotting two curves in one subplot with twinx to allow different y scales. The script below is an example. When zooming in using zoom-to-rect on Tk's navigation toolbar2 (TkAgg is my backend) I think the x axis part of the zoom is happening twice. Rubberbanding the example from x=20 to 80 results in a zoomed x range of about 32 to 68, which is about what you'd expect for zooming with the same range twice.
Is there a way of restricting this to only one zoom?
Paul
------------
from pylab import *
f=figure(1)
ax1=f.add_subplot(111)
ax1.plot(arange(100))
ax2=twinx(ax1)
ax2.plot(-arange(100),'g')
draw()
Hi,
there was the above mail on the users list.
The problem is that "release_zoom" in backend_bases.py is called twice in the above case if zoomed to a twinx'ed plot. One way to fix this behavior is to set a "twin" attribute to the axes instance. Attached is a patch against the 0.91 trunk.
John: is this okay or is there a better way to fix the problem?
Manuel
Ups - the last patch didn't work correctly since the y-axis of the twin'ed plot wasn't scaled correctly. So I try it again 
Manuel
twinzoom.patch (3.71 KB)
Hi,
I have fixed the double-zoom Bug in the trunk (revision 5053), but not in the 0_91maint branch. In 0.91 it's not so easy to find out whether an axes is shared with another (cbook:Group is nice 
) For 0.91: is it always guaranteed that the release_zoom event for the master is called before that of the shared axes ? (I don't think so.) Then it would be more easy to test for the shared axes ...
So there is still the old solution (see previous post) to introduce an argument twinx,twiny #%$(/"/'+*#*# I don't like that.
Manuel
Hey Manuel, thanks for fixng this. I don't think it is critical that
this be fixed on the maintenance branch since it is a relatively small
bug (only applies in twinned axes) but I have a minor suggestion for
you in the fix for the trunk. It is not a good idea for a class
outside the axes to access a "protected" "_twinx" attribute. Probably
better is to either make the attribute public by naming it "istwinx"
or something like that, or make a method.
JDH
···
On Mon, Apr 7, 2008 at 8:38 AM, Manuel Metz <mmetz@...459...> wrote:
The problem is that "release_zoom" in backend_bases.py is called twice in
the above case if zoomed to a twinx'ed plot. One way to fix this behavior is
to set a "twin" attribute to the axes instance. Attached is a patch against
the 0.91 trunk.
John: is this okay or is there a better way to fix the problem?