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.