matplotlib-devel Mailing List for matplotlib

James Evans wrote:

>Andrew,
>
>The easiest way to see this bug is to use the QtAgg backend, then type the following:
>
>  
>
>>>>import pylab
>>>>pylab.figure(figsize=(1, 1))
>>>>pylab.show()
>>>>        
>>>>
>
>and the window you get will most definitly not be using the sizes you set forth.
>  
>
OK, I see the issue using QtAgg. Patched in 2143.

I thought I tested the resize events by, well, resizing windows by
dragging the corner, and everything seemed fine. Strangely, though, the
patch I just applied doesn't seem necessary on a Qt (not QtAgg) backend.

>>>>> "James" == James Evans <jre...@ea...> writes:

    James> the problem being that this will only set the property of
    James> the first 'n' labels, where 'n' is the number of tickmarks
    James> present when you initially set the property.  So if the
    James> number of tick marks increases when zooming in (or out),
    James> then the remaining labels above 'n' will not have the
    James> property set.  You can see this by running the example
    James> script "simple_plot.py" and rotating the labels (as above)
    James> and then zooming in and out until you have more than the
    James> initial number of ticks.

Hmm, this shouldn't happen.  There is logic in the axis class when
creating a new tick to copy the properties of the existing ticks.
There is a "protoTick" ie the prototype tick, which is used to get the
properties when creating a new tick.  The Axis._copy_tick_props method
is used to transfer the properties from the protoTick to the new tick.
That in turn calls the "update_from" method of the text instances,
which does copy the rotation value.

So it *should* work on a quick code read, but clearly it doesn't from
your reported problem.  You may want to poke around this section of
the code to see where the logic is failing.

JDH

John,

I had noticed that as well, and when I used it I was rotating the labels by "-90" degrees to
see them more clearly.  But doing so uncovers a bug/feature when using any AutoTickLocator
mechanism.

When you want to rotate the labels, you do so by doing something like the following:

>>> ax = subplot(111)
>>> plot_date(dates, values, '-')
>>> labels.ax.get_xticklabels()
>>> setp(labels, rotation=-90)

the problem being that this will only set the property of the first 'n' labels, where 'n' is
the number of tickmarks present when you initially set the property.  So if the number of
tick marks increases when zooming in (or out), then the remaining labels above 'n' will not
have the property set.  You can see this by running the example script "simple_plot.py" and
rotating the labels (as above) and then zooming in and out until you have more than the
initial number of ticks.

Perhaps a solution would be to set "default" properties for the axis in question, which
would then always set those properties for the tickmarks, unless specifically overridden by
the user as in the above case.

--James Evans


-----Original Message-----
From: John Hunter [mailto:jdh...@ac...] 
Sent: Monday, March 13, 2006 7:54 AM
To: Andrew Straw
Cc: James Evans; mat...@li...
Subject: Re: [matplotlib-devel] AutoDateLocator

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Committed into svn 2142.

Thanks for the patch James, the auto date functionality is very
nice.  Just a minor comment.  In the load_converter.py example, the
default ticks overlap each other with the default window size.  I
think we are using a format string that is too long for this date
range.

JDH

>>>>> "Andrew" == Andrew Straw <str...@as...> writes:

    Andrew> Committed into svn 2142.

Thanks for the patch James, the auto date functionality is very
nice.  Just a minor comment.  In the load_converter.py example, the
default ticks overlap each other with the default window size.  I
think we are using a format string that is too long for this date
range.

JDH

Andrew,

The easiest way to see this bug is to use the QtAgg backend, then type the following:

>>> import pylab
>>> pylab.figure(figsize=(1, 1))
>>> pylab.show()

and the window you get will most definitly not be using the sizes you set forth.

--James Evans


-----Original Message-----
From: Andrew Straw [mailto:str...@as...] 
Sent: Sunday, March 12, 2006 12:01 PM
To: James Evans; mat...@li...
Subject: Re: [matplotlib-devel] (no subject)

James Evans wrote:

>When using the Qt backend, resize events were not
>getting passed along properly so the window was created
>based off of some other criteria. The attatched patch
>file will fix the problem and make the window be
>resized appropriatly on construction.
>
>  
>
Admittedly I'm no Qt person (this was my opportunity to install Qt on my
system), but I couldn't find any problems with the current
implementation. Could you give a specific, reproducible problem case
that your patch fixes?

Cheers!
Andrew

Tennessee,

Maybe I missed it, but I did not see any reply to your message.  We 
welcome simple scripts that expose bugs--and the simpler the better.  If 
something more than a simple script is required, then instead of sending 
  a big file to the list, you could put it on an ftp server if you have 
access to one, or send it to one of us off-list upon request.

Tennessee Leeuwenburg wrote:
[...]
> I wrote some code to generate a pair of lists about 300 elements long,
> and plotted them. I found that the line plot didn't have all the data
> points connected.
What backend were you using, and what operating system?  What mpl 
version?   Was the lack of connectedness at the level of a missing 
pixel, or was a whole line segment missing?
> 
> When I saved to SVG, the output was correct.
So it sounds like it must be a problem with a particular backend.
> 
> Also, when I tried to perform a scatter plot, I got runtime errors and
> no plot was drawn. These problems occur 100% of the time on my machine
> with my test files.
Until a recent change in SVN, scatter required an array, not a list, for 
its colors argument.  Could this be the problem in your case?

> 
> I'm not sure if this list accepts files or not, but I am happy to
> provide the code and sample files which demonstrate this error, and/or
> respond to the bugfixing process.

Eric