matplotlib-devel Mailing List for matplotlib

>>>>> "John" == John Hunter <jdh...@ac...> writes:

    John> I have tested a few backends (TkAgg, WX, QtAgg, GTK and
    John> GTKAgg) and am only seeing it on GTK and GTKAgg.  My guess
    John> is that something ou did in adding the resize functionality
    John> to GTK is triggering this.  You might want to look at a diff
    John> between the current svn and revision 2627 to see if you can
    John> find the source of this.

Scratch that -- I reverted to 2627 and still see it...

JDH

On Thursday 10 August 2006 11:17, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> I fixed that problem in the qt backends by telling the
>     Darren> label to ignore sizing hints. We could make the format
>     Darren> string shorter, but even then, depending on the size of
>     Darren> the window, this problem can occur. What format would you
>     Darren> prefer to be reported on the toolbar?
>
> I'm a little confused here because the default should be to use the
> axis major formatter (eg in the Axes.format_xdata function).  Why
> would the default formatter return such a long string?

I think it is to support for small ranges on top of very large numbers. I 
think the fix you suggest below will work for now (I had to make an 
additional change to format the offset label correctly, svn 2668), and I can 
clean up the default formatter later. I don't want to rush through that. 
People have asked for on more than one occassion for engineering notation: 
tick labels that read 2x10^-5, they would read 20x10^-6, and I think this 
would work with the shorter string formatting.

> I don't know what the right answer is: using the default formatter is
> usually irritating when plotting dates, since you often want a finer
> resolution than you get with the tick formatting (eg if the ticks are
> formatted to the nearest day, you may want to see H:M:S when
> interacting).  Clearly you can override this by using the fmt_xdata
> and fmt_ydata attrs, but oftentimes I wish the defaults were better.
>
> As a quick solution, I added a default method to the Formatter base
> class
>
>     def format_data_short(self,value):
>         'return a short string version'
>         return format_data(self,value)
>
> and overrode it for the scalar formatter
>
>     def format_data_short(self,value):
>         'return a short formatted string representation of a number'
>         return '%1.3g'%value
>
>
> and used this to format the x and y coords.  What do you think about
> that (revision 2666)?
>
> JDH
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> I periodically am seeing it.  But I can't figure out how
    Charlie> to cause it.

I have tested a few backends (TkAgg, WX, QtAgg, GTK and GTKAgg) and am
only seeing it on GTK and GTKAgg.  My guess is that something ou did
in adding the resize functionality to GTK is triggering this.  You
might want to look at a diff between the current svn and revision
2627 to see if you can find the source of this.

peds-pc311:~/mpl> svn log lib/matplotlib/backends/backend_gtk.py |
head -20
------------------------------------------------------------------------
r2628 | cmoad | 2006-07-28 12:58:58 -0500 (Fri, 28 Jul 2006) | 1 line

fixed qt subplots button. added FigureManager.resize method
------------------------------------------------------------------------
r2502 | jdh2358 | 2006-06-21 08:22:31 -0500 (Wed, 21 Jun 2006) | 1
line

added custom figure class hook
------------------------------------------------------------------------
r2476 | efiring | 2006-06-12 12:36:06 -0500 (Mon, 12 Jun 2006) | 2
lines

GTK backend: don't draw line if linewidth==0.

------------------------------------------------------------------------
r2384 | stevech | 2006-05-08 01:40:08 -0500 (Mon, 08 May 2006) | 2
lines

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> I just tried running backend_driver.py with numerix set to
    Darren> Numeric, and I'm repeatedly getting the following error:

    Darren>   File
    Darren> "/usr/lib64/python2.4/site-packages/matplotlib/axes.py",
    Darren> line 2502, in bar yerr = asarray([yerr]*nbars, Float) #
    Darren> Float converts Nones to NANs File
    Darren> "/usr/lib64/python2.4/site-packages/Numeric/Numeric.py",
    Darren> line 134, in asarray return multiarray.array(a, typecode,
    Darren> copy=0, savespace=savespace) TypeError: a float is
    Darren> required driving image_demo.py

That was in histogram_demo which called bar with xerr=None and
yerr=None and bar was assuming a numpy-ism in converting None to nan.
I just committed a change to fix it.

JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
    Darren> I fixed that problem in the qt backends by telling the
    Darren> label to ignore sizing hints. We could make the format
    Darren> string shorter, but even then, depending on the size of
    Darren> the window, this problem can occur. What format would you
    Darren> prefer to be reported on the toolbar?

I'm a little confused here because the default should be to use the
axis major formatter (eg in the Axes.format_xdata function).  Why
would the default formatter return such a long string?

I don't know what the right answer is: using the default formatter is
usually irritating when plotting dates, since you often want a finer
resolution than you get with the tick formatting (eg if the ticks are
formatted to the nearest day, you may want to see H:M:S when
interacting).  Clearly you can override this by using the fmt_xdata
and fmt_ydata attrs, but oftentimes I wish the defaults were better.

As a quick solution, I added a default method to the Formatter base
class

    def format_data_short(self,value):
        'return a short string version'
        return format_data(self,value)

and overrode it for the scalar formatter

    def format_data_short(self,value):
        'return a short formatted string representation of a number'
        return '%1.3g'%value


and used this to format the x and y coords.  What do you think about
that (revision 2666)?

JDH

On Thursday 10 August 2006 10:54, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
>     Charlie> I periodically am seeing it.  But I can't figure out how
>
> I just tested on TkAgg ( I usually use GTKAgg) and noticed another
> problem.  When you click "zoom to rect mode" the format string in the
> toolbar becomes so long that it causes the window to resize to fit
> it.  As you move the mouse around, depending on the x and y
> locations, the format string becomes longer or shorter and the window
> resizes like mad.  Very annoying.  Let's hold off on a release until
> we can sort these bugs out.

I just tried running backend_driver.py with numerix set to Numeric, and I'm 
repeatedly getting the following error:

  File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 2502, in 
bar
    yerr = asarray([yerr]*nbars, Float) # Float converts Nones to NANs
  File "/usr/lib64/python2.4/site-packages/Numeric/Numeric.py", line 134, in 
asarray
    return multiarray.array(a, typecode, copy=0, savespace=savespace)
TypeError: a float is required
 driving image_demo.py

Darren

On Thursday 10 August 2006 10:54, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
>     Charlie> I periodically am seeing it.  But I can't figure out how
>
> I just tested on TkAgg ( I usually use GTKAgg) and noticed another
> problem.  When you click "zoom to rect mode" the format string in the
> toolbar becomes so long that it causes the window to resize to fit
> it.  As you move the mouse around, depending on the x and y
> locations, the format string becomes longer or shorter and the window
> resizes like mad.  Very annoying.  Let's hold off on a release until
> we can sort these bugs out.

I fixed that problem in the qt backends by telling the label to ignore sizing 
hints. We could make the format string shorter, but even then, depending on 
the size of the window, this problem can occur. What format would you prefer 
to be reported on the toolbar?

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:

    Charlie> I periodically am seeing it.  But I can't figure out how

I just tested on TkAgg ( I usually use GTKAgg) and noticed another
problem.  When you click "zoom to rect mode" the format string in the
toolbar becomes so long that it causes the window to resize to fit
it.  As you move the mouse around, depending on the x and y
locations, the format string becomes longer or shorter and the window
resizes like mad.  Very annoying.  Let's hold off on a release until
we can sort these bugs out.

JDH

On 8/10/06, John Hunter <jdh...@ac...> wrote:
>
> I am experiencing some strangeness with the svn version of mpl, but I
> don't know if it is the code or my connection.  I am working over X11
> so it may have something to do with that.  Could those of you with
> local access to an svn install of mpl test something?
>
> When I open a plot (eg simple_plot.py) and zoom to rect, the plot
> zooms in to the rect, and then strangely zooms back out to the
> original view and then back in again.  Anyone else seeing this?

I periodically am seeing it.  But I can't figure out how to cause it.

I am experiencing some strangeness with the svn version of mpl, but I
don't know if it is the code or my connection.  I am working over X11
so it may have something to do with that.  Could those of you with
local access to an svn install of mpl test something?

When I open a plot (eg simple_plot.py) and zoom to rect, the plot
zooms in to the rect, and then strangely zooms back out to the
original view and then back in again.  Anyone else seeing this?

JDH