matplotlib-devel Mailing List for matplotlib

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

    Darren> When I run the following: figure(); plot([1,2]) figure();
    Darren> plot([1,2])

    Darren> and then I use the zoom widget in one figure, and then try
    Darren> to use the zoom widget in the other figure without turning
    Darren> off the first zoom widget, I get an error. Is this
    Darren> desirable?

No -- I hadn't considered this use case.  The locking should be on a
per figure basis.  I introduced locking to handle the case where
someone wants to use a widget that draws onto the canvas (like the
lasso tool) w/o interfering with the other tools that are handling
events.  Eg, if pan/zoom is enabled and you are also trying to draw a
lasso, all hell breaks loose.

I've commented this out and will re-implement after further
consideration.  Thanks for the heads-up.

JDH

When I run the following:

figure(); plot([1,2])
figure(); plot([1,2])

and then I use the zoom widget in one figure, and then try to use the zoom 
widget in the other figure without turning off the first zoom widget, I get 
an error. Is this desirable?

---------------------------------------------------------------------------
exceptions.ValueError                                Traceback (most recent 
call last)

/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_qt.py in 
zoom(self, *args)
    305     def zoom( self, *args ):
    306         self.buttons[ 'Pan' ].setOn( False )
--> 307         NavigationToolbar2.zoom( self, *args )
    308
    309     def dynamic_update( self ):

/usr/lib64/python2.4/site-packages/matplotlib/backend_bases.py in zoom(self, 
*args)
   1564             self._idRelease = 
self.canvas.mpl_connect('button_release_event', self.release_zoom)
   1565             self.mode = 'Zoom to rect mode'
-> 1566             widgets.lock(self)
   1567         else:
   1568             #pass

/usr/lib64/python2.4/site-packages/matplotlib/widgets.py in __call__(self, o)
     31         'reserve the lock for o'
     32         if not self.available(o):
---> 33             raise ValueError('already locked')
     34         self._owner = o
     35

ValueError: already locked



Darren

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

    Darren> return self.format_data(value)

    Darren> I'm not sure what you had in mind.

Oops:

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


Fixed in svn

JDH

On Thursday 10 August 2006 11:17, John Hunter wrote:
> 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)

I think there is a bug here. Maybe that last line should read

return Formatter.format_data(self,value)

or 

return self.format_data(value)

I'm not sure what you had in mind.