matplotlib-devel Mailing List for matplotlib

While trying to track down the zoom bug reported by David Trem, I got 
all tangled up in what appear to be completely obsolete and unneeded 
"zoom" etc. methods. These are left over from the original 
NavigationToolbar and the pre-transforms code. I would like to see all 
of this, including the entire original NavigationToolbar, deprecated and 
then removed. My guess is that no one is actually using any of it.
Comments? Does anyone know of other cruft that we might be able to 
clean out?
Eric

It works perfectly now using svn 6776
Thanks very much to be so efficient in killing bugs !
Less than three hours after my small bug report... I'm really impressed!
David
Eric Firing a écrit :
> John Hunter wrote:
>> On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...>
>> wrote:
>>> Hi,
>>>
>>> I've just discover a problem with the pan/zoom tool.
>>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>>> zoom does not work correctly.
>>> To visualize the problem launch the small script in attachment press the
>>> pan/zoom button and use the zoom on the x axis direction -> you will see
>>> the button part of the curve directly jumping at the bottom of the graph
>>> whereas you would expected it not to move...
>>> I evidence this problem using GTKAgg but also with the OSX backend (did
>>> not try other backend).
>>> Matplotlib version is the latest svn on a MacOS X platform.
>>
>> I don't think I see this -- if you hold down the 'x' while you are
>> panning, the zoom will be constrained in the x direction and I see no
>> unusual movement. If I release the 'x' but still zoom horizontally,
>> there is some motion in the vertical direction, but that is because I
>> cannot move precisely horizontally. Could you be more precise about
>> the artifact you are seeing. For me, the bottom part of the curve is
>> at (0, 10^0) and and I do not see any unusual behavior there
> 
> John,
> 
> I reproduced the problem (jumpy boundary with log scale and zoom) and
> fixed it in my last two commits (6773 to maint and 6775 merging to trunk).
> 
> Eric
> 
> 
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the new SourceForge.net Marketplace.
>> It is the best place to buy or sell services for
>> just about anything Open Source.
>> http://p.sf.net/sfu/Xq1LFB
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Sat, Jan 10, 2009 at 2:49 PM, Darren Dale <dsd...@gm...> wrote:
>> Never had any luck getting a tester, so I went ahead and committed
>> this to the trunk. I should probably get a working qt backend for
>> testing on one of the machines I use....
>
> I'm sorry John, I didnt see your original request for testing.
>
> I tried running the following with interactive on and off:
> I didnt notice any significant diffference in speed in the two modes with
> the qt4agg backend, and the figures looked fine. Is there anything else I
> should be looking for?
No, that should do it -- thanks for taking a look.
JDH

John Hunter wrote:
> On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...> wrote:
>> Hi,
>>
>> I've just discover a problem with the pan/zoom tool.
>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>> zoom does not work correctly.
>> To visualize the problem launch the small script in attachment press the
>> pan/zoom button and use the zoom on the x axis direction -> you will see
>> the button part of the curve directly jumping at the bottom of the graph
>> whereas you would expected it not to move...
>> I evidence this problem using GTKAgg but also with the OSX backend (did
>> not try other backend).
>> Matplotlib version is the latest svn on a MacOS X platform.
> 
> I don't think I see this -- if you hold down the 'x' while you are
> panning, the zoom will be constrained in the x direction and I see no
> unusual movement. If I release the 'x' but still zoom horizontally,
> there is some motion in the vertical direction, but that is because I
> cannot move precisely horizontally. Could you be more precise about
> the artifact you are seeing. For me, the bottom part of the curve is
> at (0, 10^0) and and I do not see any unusual behavior there
John,
I reproduced the problem (jumpy boundary with log scale and zoom) and 
fixed it in my last two commits (6773 to maint and 6775 merging to trunk).
Eric
> 
> ------------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Jan 10, 2009 at 3:09 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 30, 2008 at 10:57 AM, John Hunter <jd...@gm...> wrote:
> > On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon <mjl...@ya...>
> wrote:
> >
> >> I have written such a function for the qt4 backend; see patch #2468809
> at
> >>
> >>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2468809&group_id=80706&atid=560722
> >>
> >> I am not a big qt4 user, so it would be good if somebody else could look
> at this patch before adding it to the trunk.
> >
> > I would like to apply this patch, but I am not a qt user either, so if
> > someone could test this and get back to us, that would be great.
>
> Never had any luck getting a tester, so I went ahead and committed
> this to the trunk. I should probably get a working qt backend for
> testing on one of the machines I use....
>
I'm sorry John, I didnt see your original request for testing.
I tried running the following with interactive on and off:
from pylab import *
import numpy
figure()
x=numpy.arange(20)
y=1+x**2
n = 4
for i in range(n*n):
 subplot(n,n,i+1)
 bar(x,y,log=True)
 xlim(-5,25)
 ylim(1,1e4)
I didnt notice any significant diffference in speed in the two modes with
the qt4agg backend, and the figures looked fine. Is there anything else I
should be looking for?
Darren

On Tue, Dec 30, 2008 at 10:57 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon <mjl...@ya...> wrote:
>
>> I have written such a function for the qt4 backend; see patch #2468809 at
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2468809&group_id=80706&atid=560722
>>
>> I am not a big qt4 user, so it would be good if somebody else could look at this patch before adding it to the trunk.
>
> I would like to apply this patch, but I am not a qt user either, so if
> someone could test this and get back to us, that would be great.
Never had any luck getting a tester, so I went ahead and committed
this to the trunk. I should probably get a working qt backend for
testing on one of the machines I use....
JDH

On Sat, Jan 10, 2009 at 9:28 AM, Michiel de Hoon <mjl...@ya...> wrote:
> I've written a patch for the Mac OS X native backend to make use of the new hatching support; see patch #2497785 at
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2497785&group_id=80706&atid=560722
>
> I tested this with the new hatch_demo.py in SVN trunk, and it seems to work fine.
Thanks Michiel, I committed this patch to the trunk and closed the
item on the sf tracker.
JDH

On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...> wrote:
> Hi,
>
> I've just discover a problem with the pan/zoom tool.
> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
> zoom does not work correctly.
> To visualize the problem launch the small script in attachment press the
> pan/zoom button and use the zoom on the x axis direction -> you will see
> the button part of the curve directly jumping at the bottom of the graph
> whereas you would expected it not to move...
> I evidence this problem using GTKAgg but also with the OSX backend (did
> not try other backend).
> Matplotlib version is the latest svn on a MacOS X platform.
I don't think I see this -- if you hold down the 'x' while you are
panning, the zoom will be constrained in the x direction and I see no
unusual movement. If I release the 'x' but still zoom horizontally,
there is some motion in the vertical direction, but that is because I
cannot move precisely horizontally. Could you be more precise about
the artifact you are seeing. For me, the bottom part of the curve is
at (0, 10^0) and and I do not see any unusual behavior there

Hi,
 I've just discover a problem with the pan/zoom tool.
When using the pan/zoom tool (in the toolbar) on a semilogy plot the
zoom does not work correctly.
To visualize the problem launch the small script in attachment press the
pan/zoom button and use the zoom on the x axis direction -> you will see
the button part of the curve directly jumping at the bottom of the graph
 whereas you would expected it not to move...
I evidence this problem using GTKAgg but also with the OSX backend (did
not try other backend).
Matplotlib version is the latest svn on a MacOS X platform.
Thanks in advance,
David

I've written a patch for the Mac OS X native backend to make use of the new hatching support; see patch #2497785 at
https://sourceforge.net/tracker/index.php?func=detail&aid=2497785&group_id=80706&atid=560722
I tested this with the new hatch_demo.py in SVN trunk, and it seems to work fine.
--Michiel
--- On Mon, 12/29/08, Michael Droettboom <md...@st...> wrote:
> From: Michael Droettboom <md...@st...>
> Subject: [matplotlib-devel] Hatching support
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, December 29, 2008, 9:20 AM
> I've refactored hatching support to move the hatch
> design itself to the 
> core, added support for them in the Agg and SVG backends,
> and simplified 
> their usage in the PDF and PS backends. It should now be
> easier to add 
> new hatch styles if anyone ever feels artistic.
> 
> In order to use the same general approach in all backends,
> the PS 
> backend now uses the makepattern command rather than a loop
> to draw each 
> hatch line. That may be a regression in certain situations
> (eg., old PS 
> printers without enough memory). So those who were using
> the old PS 
> backend with hatches should test the new approach and
> report any problems.
> 
> Mike
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel