matplotlib-devel Mailing List for matplotlib

Hi Everyone,
There is a new formatter in ticker.py called NewScalarFormatter. If you have 
scientific notation in your plots, you may like the results. If you would 
like to try it out, you need to change ScalarFormatter->OldScalarFormatter, 
and NewScalarFormatter->ScalarFormatter. It will then be the default for 
linear scale axes. I would appreciate feedback, it will hopefully become the 
default at some point.
Darren

It looks like there is a bug in the text bounding boxes. It causes some 
problems in the postscript backend, where I noticed badly formatted logscale 
ticks. It looks like the bug exists in the AGG backend as well, although it 
is less noticeable there. I filed two bugs at the sf website, with images of 
bboxes that dont fit their associated text. You can also run the script 
below, but you will need a recent update of patches.py, John fixed a bug 
there today.
I assigned the PS bug to myself. If anyone has some insight, I could 
definitely use it.
Darren
http://sourceforge.net/tracker/index.php?func=detail&aid=1177396&group_id=80706&atid=560720
from pylab import *
def addtext(props):
 text(0.5, 0.5, 'xx-small', props, fontsize='xx-small')
 text(1.5, 0.5, 'x-small', props, fontsize='x-small')
 text(2.5, 0.5, 'small', props, fontsize='small')
 text(3.5, 0.5, 'medium', props, fontsize='medium')
 text(4.5, 0.5, 'large', props, fontsize='large')
 yticks([0,.5,1])
# the text bounding box
bbox = {'fc':0.8, 'pad':0} 
figure(1,figsize=(5,2))
axes()
addtext({'ha':'center', 'va':'center', 'bbox':bbox})
xlim(0,5)
savefig('/home/darren/temp/bbox.eps')
savefig('/home/darren/temp/bbox.png')
show()

Matt Newville wrote:
> For my apps, I provide interactivity by binding left-click to
> 'report x,y coords', left-down-and-drag (ie, move more than a
> few pixels) to 'Zoom to Rectangle', and have right-click bring
> up a pop-up menu with 'zoom back 1 level', 'zoom back to full
> view', and 'save image', among other things. That makes the
I'll think about it, perhaps its a better solution. With 3 buttons
and 1 wheel most of actions can be easily accessed.
> I do think it would be possible to come up with yet another
> binding mode (toolbar, toolbar2, ... no_toolbar, or toolbar0??),
> where the above behavior was provided. I don't know if that
> would be considered generally useful or not.
Probably it will be useful for me.
Marcin
--=20
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr

John Hunter wrote:
>
> What do you mean by updating plot -- calling a plot command? Calling
Yes
> "plot" and related functions does autoscale the axes -- is this the
> problem you are referring to?
Yes, that was the problem.
> It might be useful to add and
> autoscale=3DFalse option, much in the way we have a hold=3DTrue|False
> option, to the plot command, so one could issue a plot command w/o
> changing the current view lim.
>
Yes, but I would also like to allow user explicitly autoscale, ie. show
whole plot when when pressing home (or another) button.
So I don't want to change the current view lim when calling plot command,
but I want to know what the new data lims are, to be able to use it later=
.
Marcin
--=20
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr

Hi Marcin,
> And why wx and gtk toolbars are different -- in GTK button
> descriptions are in tooltips and x,y position is displayed in
> toolbar, and in wx statusbar is used? Are they different by
> design? I prefer the first way, without statusbar.
Hmm, I'd guess they're different because no one noticed or
because 'desired behavior' is not obvious. Having tooltips does
seem like a good idea, and doable, but reporting x,y to the
statusbar seems like the right place to me.
 
> And last thing: what do you think about making toolbar2 more
> hmm.. interactive(?), i mean disabled back/forward buttons
> whan there is no history, pressed pan/zoom buttons when in
> pan/zoom mode etc? I don't know if I'll try to do it, but if
> someone would do it, would it be included in MPL?
I think this is a good suggestion and not too difficult to do
for wx.
For the rest of your post, I realize this doesn't answer your
immediate questions, and may not be mpl-correct, but....:
My preference for Apps is to not use the toolbars at all. 
Maybe this is because I never used Matlab, or maybe because I
confuse toolbar and toolbar2, and don't remember the meaning of
all the icons (is the left arrow "move left" or "back one view"? 
which one is "pan/zoom" and which is "zoom to rectangle"? why
does 'axis' show up for plots with only one axis?). Also, the
toolbars take up room for something that is not used all the
time, and this functionality is (IMO) better in the menus or
toolbars of the Application or in pop-up menus. In short, I
don't think the toolbars are appropriate for Apps.
For my apps, I provide interactivity by binding left-click to
'report x,y coords', left-down-and-drag (ie, move more than a
few pixels) to 'Zoom to Rectangle', and have right-click bring
up a pop-up menu with 'zoom back 1 level', 'zoom back to full
view', and 'save image', among other things. That makes the
most important actions (report x,y, zoom in) always "on", and
the second most important actions (zoom out, save image) are
relatively easy to get to (right click on the plot then use
menu, as opposed to clicking on a toolbar button).
Maybe this negative opinion of the toolbars disqualifies me from
commenting on them (in which case, my apologies). Or maybe the
toolbars really aren't what you want in your apps, either.
I do think it would be possible to come up with yet another
binding mode (toolbar, toolbar2, ... no_toolbar, or toolbar0??),
where the above behavior was provided. I don't know if that
would be considered generally useful or not.
--Matt

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> Hi, I was trying to make updating plot not cause to change
 Marcin> zoom. I have wxPython program with embedded plot and I
 Marcin> can change some parameters what makes some changes on the
 Marcin> plot. User should be able to zoom and then change these
What do you mean by updating plot -- calling a plot command? Calling
"plot" and related functions does autoscale the axes -- is this the
problem you are referring to? It might be useful to add and
autoscale=False option, much in the way we have a hold=True|False
option, to the plot command, so one could issue a plot command w/o
changing the current view lim.
I ready through your post several times but still am not quite sure
what problem you are describing. Could you elaborate? Could you be
more specific: what are the "parameters" for example?
 Marcin> parameters and see how it influences plot, OTOH it should
 Marcin> be easy to show whole plot, eg. using home button.
 Marcin> Perhaps I'm wrong, but I think its quite common
 Marcin> requirement.
 Marcin> BTW pressing home button calls toolbar's draw() twice:
OK, I'll fix this. Thanks.
 Marcin> And why wx and gtk toolbars are different -- in GTK button
 Marcin> descriptions are in tooltips and x,y position is displayed
 Marcin> in toolbar, and in wx statusbar is used? Are they
 Marcin> different by design? I prefer the first way, without
 Marcin> statusbar.
This is mainly due to historical accident. He who write the backend
generally does it the way they want. The wx backend was the 2nd GUI
ever and there was no policy. Since then we've worked to make the
interface between the backends fairly uniform but there are some
historical differences. I don't feel strongly about it, but am
amenable to accepting a patch to change wx to behave like the other
backends.
 Marcin> And last thing: what do you think about making toolbar2
 Marcin> more hmm.. interactive(?), i mean disabled back/forward
 Marcin> buttons whan there is no history, pressed pan/zoom buttons
 Marcin> when in pan/zoom mode etc? I don't know if I'll try to do
 Marcin> it, but if someone would do it, would it be included in
 Marcin> MPL?
Yes, this would be nice. I think fltk already does this. It's mainly
a matter of getting to this to work on each and every backend. I
think Steve and I both looked at this for gtk, but couldn't an easy
way to do this. Part of the problem, I think, is that mpl is using
custom images for these buttons and it wasn't clear to me how to
indicate "pressed" status with button relief, etc... Patches gladly
accepted.
JDH