matplotlib-devel Mailing List for matplotlib (Page 4)

>>>>> "Marcin" == Marcin Wojdyr <wo...@un...> writes:
 Marcin> Proposition of the patch is attached.
OK, I've added this to my local tree and it will make it into CVS
before too long. Those with an interest in tk, gtk, qt might want to
consider a similar patch to those backends.
 Marcin> BTW could you have a look at
 Marcin> http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
 Marcin> Does it makes a sense?
Sorry I didn't respond earlier -- a combination of being out of the
country in combination with a hard-drive failure have left me in
catch-up mode. Thanks for the reminder
I don't like the idea of making the label a string or None, because it
leads to code that is difficult to maintain and may break existing
code that relies on the label to be a string. I would be amenable to
using a sentinel string, such as '_nolegend_' or something like that.
JDH

On Sun, 1 May 2005, John Hunter wrote:
> 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
I haven't installed fltk, but had a look at code, and I think it does
toggled pan/zoom buttons, but not enabled/disabled back/forward.
> 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.
Proposition of the patch is attached. 
BTW could you have a look at 
http://sourceforge.net/mailarchive/forum.php?thread_id=7056275&forum_id=36187
Does it makes a sense?
Marcin
-- 
Marcin Wojdyr | http://www.unipress.waw.pl/~wojdyr/ 

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 >> To fix this one should get the kerning information from the
 >> font, and do the kerning manually. Have a look at dvips output
 >> to get inspiration.
Now that we understand the problem, we have two options.
 * We can manually do the kerning in draw_text for the truetype
 fonts. This won't be hard because we can just follow the example
 of draw_unicode with minor modifications. This will be a little
 slower and make ps files a little bigger, but will look the best.
 * we can add a kwarg to font.get_width_height() to ignore kerning
 information, and backend ps can call
 font.get_width_height(kerning=False). 
 Darren> I also had a look at the dvips output, and get the general
 Darren> idea of how it handles layout. So let me ask, why does
 Darren> mathtext break with afm fonts? Is it inherent, or could
 Darren> mathtext.py (or backend_ps.py) be changed to cooperate
 Darren> with afm? From looking at the dvips output, a naive
 Darren> individual like myself might think it is pretty straight
 Darren> forward to render something like r'My test string
 Darren> $A=A_0e^(i\theta)$'. (I'm not saying it would be easy to
 Darren> implement.)
 Darren> Dvips embeds four fonts to render my example string:
 Darren> CMMI7, CMR7, CMMI10, CMR10. Here is the output, I clipped
 Darren> the start of the file up to the end of the font defs:
I started working with AFM fonts in my initial implementation of
mathtext, but before I got too far Paul took on the task of porting
mathtext to PS and decided to embed the truetype fonts. This has the
advantage of having your postscript figure and screen figure look
nearly identical and also just gives us a single point of maintenance
in the mathtext module. But there are problems as well, as you've
noticed
 * the bakoma fonts suck in my opinion, some glyphs render poorly.
 Paul and I were never able to figure out how the vertical offsets
 in cmex worked, they have licensing problems
 * the use of bakoma fonts for mathtext and other fonts for the rest
 of the figure looks bad, and may be unacceptable for publication.
 One solution is to use cmr as your default font (set the rc param)
 but then see the problem above.
We could go the route of embedding type1 fonts and using afm files for
layout -- this wouldn't be too hard. But our energy might be best
served by converting the mathtext data tables to map text characters
to unicode and then using a set of unicode fonts, using freefont for
now (GPLd I think)
 http://sourceforge.net/mailarchive/forum.php?thread_id=7090823&forum_id=36187
and STIX fonts when they are done http://www.stixfonts.org (which
should be just a few months according to their web site, but then
again their FAQ says "The STIX Fonts will not be completed until some
time in 2003" so we should be cautious....)
See also 
 http://www.mozilla.org/projects/mathml/fonts/
I realize you have a thesis to print, so hopefully we can figure out a
smooth path to success soon! When do you need to turn that thing in?
JDH

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself. It is a small effect, but visible. This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV". Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually. Have a look at dvips output to get
> inspiration.
I just finished reading Adobe's Technical Note #5012: The Type 42 Font Format 
Specification. The only mention of kerning is on page 12, indicating that 
performance can be improved by including only those type 42 tables that are 
actually used by the TrueType rasterizer. It implies that kerning tables are 
not used.
I also had a look at the dvips output, and get the general idea of how it 
handles layout. So let me ask, why does mathtext break with afm fonts? Is it 
inherent, or could mathtext.py (or backend_ps.py) be changed to cooperate 
with afm? From looking at the dvips output, a naive individual like myself 
might think it is pretty straight forward to render something like 
r'My test string $A=A_0e^(i\theta)$'. 
(I'm not saying it would be easy to implement.)
Dvips embeds four fonts to render my example string: CMMI7, CMR7, CMMI10, 
CMR10. Here is the output, I clipped the start of the file up to the end of 
the font defs:
>%%EndFont 
>TeXDict begin 40258431 52099146 1000 600 600 (temp.dvi)
>@start /Fa 150[23 86[32 18[{}2 58.1154 /CMMI7 rf /Fb
>207[33 48[{}1 58.1154 /CMR7 rf /Fc 154[39 35[62 65[{}2
>83.022 /CMMI10 rf /Fd 134[44 4[32 33 33 3[46 4[23 1[42
>1[37 23[76 15[65 11[42 49[{}11 83.022 /CMR10 rf end
>%%EndProlog
>%%BeginSetup
>%%Feature: *Resolution 600dpi
>TeXDict begin
> end
>%%EndSetup
>%%Page: 1 1
I'm not sure what that first block is doing (yet), but here is the important 
part:
>TeXDict begin 1 0 bop 639 523 a Fd(My)28 b(test)g(string)f
>Fc(A)c Fd(=)g Fc(A)1420 535 y Fb(0)1457 523 y Fc(e)1496
>493 y Fa(i022円)1926 5255 y Fd(1)p eop end
Its essentially a group of moveto statements and font changes. It looks like 
the kerning support is sort of a hybrid, where you dont have to layout each 
glyph independently, but layout is done manually between groups of glyphs.
I guess I havent considered rendering in AGG.
Darren

Hi,
I have installed matplotlib-0.80 on WinXP and when I run a Python script 
that calls pylab.plot
several times after a while the program ends with the error message 
listed below. I inserted some print statements into backend_agg.py and 
text.py (code snippets see below). As far as I can see the problem is 
with the function xy_tup that returns (70.0555555556, -3509680569.77) 
when given the input (-0.030476944389471572, -0.012864052691159839).
My workaround is to set:
try:
 self._renderer.draw_text(font, int(x), int(y), gc)
except:
 pass
in backend_agg.py
Is there anything I can do instead to avoid this error message?
With kind regards
Rolf Wester
-------------------------------------------------------------------------------------------------
text.py
 def draw(self, renderer):
 ...
 
 bbox, info = self._get_layout(renderer)
-> print "draw ", info,
 for line, wh, x, y in info:
 x, y = self._transform.xy_tup((x, y))
-> print x,y," / ",
 #renderer.draw_arc(gc, (1,0,0),
 # x, y, 2, 2, 0.0, 360.0)
 if renderer.flipy():
 canvasw, canvash = renderer.get_canvas_width_height()
 y = canvash-y
-> print y, canvash
 
 renderer.draw_text(gc, x, y, line,
 self._fontproperties, angle,
 ismath=self.is_math_text())
------------------------------------------------
backend_agg.py:
 def draw_text(self, gc, x, y, s, prop, angle, ismath):
 """
 Render the text
 """
 if __debug__: verbose.report('RendererAgg.draw_text', 
'debug-annoying')
 if ismath:
 return self.draw_mathtext(gc, x, y, s, prop, angle)
 font = self._get_agg_font(prop)
 if font is None: return None
 if len(s)==1 and ord(s)>127:
 font.load_char(ord(s))
 else:
 font.set_text(s, angle)
 font.draw_glyphs_to_bitmap()
-> print font, int(x), int(y), gc
 self._renderer.draw_text(font, int(x), int(y), gc)
--------------------------------------------------------------
Shell
...
draw [('0', (7.0, 10.0), -0.030476944389471572, -0.012864052691159839)] 
70.0555555556 -3509680569.77 / 3509681061.77 492.0
<FT2Font object at 0x0132DEAC> 70 3509681061 
<matplotlib.backend_bases.GraphicsContextBase instance at 0x1B340F80>
Traceback (most recent call last):
 File "E:\work\trumpf\kaustikopti6659mmAK2ma.py", line 238, in -toplevel-
 intensity_nf, intensity_ff = opt_resonator_online(GRIDLIST, OELIST, 
outcoupler, SEQUENCELIST1, SEQUENCELIST2, no_fc, init_kind, nit, nav, 
verbose=verbose, plot = plot, genplot = gen_plot)
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_resonator.py", 
line 473, in opt_resonator_online
 if plot: genplot.plot_slice(fc_outcouple, ifigure = 2, clear = 
'yes', nr = 1, nc = 2, nf = 1, slice = 1, xlabel = '$r$', i=0, 
ylabel = '$Intensity$', title = '$nearfield$')
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 507, in plot_slice
 xlabel = xlabel, ylabel = ylabel, title = title)
 File "D:\PROGLA~1\Python23\lib\site-packages\OPT\opt_graphics.py", 
line 560, in plot_slice_matplotlib
 pylab.plot(x,xslice)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\pylab.py", 
line 1900, in plot
 draw_if_interactive()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 58, in draw_if_interactive
 figManager.show()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 292, in show
 self.canvas.draw()
 File 
"D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\backends\backend_tkagg.py", 
line 146, in draw
 FigureCanvasAgg.draw(self)
 File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 312, in draw
 self.figure.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\figure.py", 
line 395, in draw
 for a in self.axes: a.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axes.py", line 
1362, in draw
 self.yaxis.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
524, in draw
 tick.draw(renderer)
 File "D:\PROGLA~1\Python23\Lib\site-packages\matplotlib\axis.py", line 
141, in draw
 if self.label1On: self.label1.draw(renderer)
 File "D:\PROGLA~1\Python23\lib\site-packages\matplotlib\text.py", line 
332, in draw
 ismath=self.is_math_text())
 File 
"D:\PROGLA~1\Python23\lib\site-packages\matplotlib\backends\backend_agg.py", 
line 211, in draw_text
 self._renderer.draw_text(font, int(x), int(y), gc)
TypeError: CXX: type error.
 >>>
-- 
-------------------------------------
Rolf Wester
rol...@il...

On Tuesday 03 May 2005 9:51 am, Jochen Voss wrote:
> Hi Darren,
>
> On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> > I assigned the PS bug to myself. If anyone has some insight, I could
> > definitely use it.
>
> Sorry, I do not have much time at the moment, but I remember
> something: the PostScript driver always got the horizontal text
> extents slightly wrong, because PostScript seems to not do kerning by
> itself. It is a small effect, but visible. This is especially
> visible when comparing strings like "AAAAA" and "AVAVAV". Is this
> what you are seeing?
>
> To fix this one should get the kerning information from the font,
> and do the kerning manually. Have a look at dvips output to get
> inspiration.
Hi Jochen,
Thanks for responding. I'll continue looking into this tomorrow. For now, I 
posted a new eps file in the sourceforge bugreport, which renders the 
suggested strings. You are right, the effect is especially visible when 
rendering 'AVAVAV'.
By the way, did you know MoonBuggy is in the gentoo package management tree?
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...

Hi Darren,
On Mon, May 02, 2005 at 04:03:17PM -0400, Darren Dale wrote:
> I assigned the PS bug to myself. If anyone has some insight, I could=20
> definitely use it.
Sorry, I do not have much time at the moment, but I remember
something: the PostScript driver always got the horizontal text
extents slightly wrong, because PostScript seems to not do kerning by
itself. It is a small effect, but visible. This is especially
visible when comparing strings like "AAAAA" and "AVAVAV". Is this
what you are seeing?
To fix this one should get the kerning information from the font,
and do the kerning manually. Have a look at dvips output to get
inspiration.
All the best,
Jochen
--=20
http://seehuhn.de/

On May 3, 2005, at 6:11 PM, John Hunter wrote:
>>>>>> "Darren" == Darren Dale <dd...@co...> writes:
> Darren> I'm amazed at the amount of effort required to handle
> Darren> fonts properly.
>
> Deranged scientist in Chicago laughs maniacally....
>
It's not much appreciated that handling fonts well is one of the 
hardest aspects of any multiplatform plotting package (at least that's 
what I think).

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> If anyone can offer advice, I am a little desperate. Half
 Darren> of my plots are logscale, so I need to fix this in order
 Darren> to generate figures for my thesis. Is there anywhere I
 Darren> can look to learn the basics of dealing with fonts at this
 Darren> level? Any recommendations on C++ crash courses?
I have an idea -- it may be that the freetype module and postscript
are handling kerning differently. If for some reason freetype is
applying more kerning than the postscript machine you are rendering
with, then the bounding boxes will be smaller than the rendered ps
text. Consider this example -- the only difference between the two
strings is that in the unicode version I lay out the text character by
character and manually do the kerning myself (since postscript doesn't
have unicode I do the layout glyph-by-glyph basis)
 import pylab as p
 p.text(1,2,'AVA', fontsize=80, bbox={'pad':0})
 p.text(1,1,u'AVA', fontsize=80, bbox={'pad':0})
 p.grid()
 p.axis([0,3,0,3])
 p.savefig('test.png')
 p.savefig('test.ps')
 p.show()
The important point is that only in the regular text is the bounding
box wrong, which supports my hunch that there are different levels of
kerning in the default ps text. 
Is the kerning information getting embedded?
Do some research on embedded truetype fonts and postscript kerning and
see if anything turns up.
We might consider using the unicode layout engine for *all* text as a
quick fix. We would pay a performance cost to do this, and it might
break numerical superscripting temporarily....
 Darren> I'm amazed at the amount of effort required to handle
 Darren> fonts properly.
Deranged scientist in Chicago laughs maniacally....
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I have a little more information. When I set ps.useafm
 Darren> =True in .matplotlibrc, eps output looks good, there is no
 Darren> mismatch between the bboxes and the text. I'm guessing
 Darren> the bug may be in either backend_ps.encodeTTFasPS, or
 Darren> somewhere in ft2font.h. Unfortunately, I have zarro
 Darren> experience with C++, so I'm having a hard time
 Darren> interpretting ft2font.
 Darren> If anyone can offer advice, I am a little desperate. Half
 Darren> of my plots are logscale, so I need to fix this in order
 Darren> to generate figures for my thesis. Is there anywhere I
 Darren> can look to learn the basics of dealing with fonts at this
 Darren> level? Any recommendations on C++ crash courses?
I don't think the bug is in ft2font for the simple reason that the
same ft2font code is being used to do the agg layout and the ps
layout (and agg is pretty close to right). It could be that we are
not setting the dpi and fontsize in backend ps, it could be that we
are not setting some scale parameter when we embed the fonts in ps,
I'm not sure. Did you get a chance to send a figure to the printer
yet?
JDH

On Monday 02 May 2005 4:03 pm, Darren Dale wrote:
> 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 have a little more information. When I set ps.useafm =True in .matplotlibrc, 
eps output looks good, there is no mismatch between the bboxes and the text. 
I'm guessing the bug may be in either backend_ps.encodeTTFasPS, or somewhere 
in ft2font.h. Unfortunately, I have zarro experience with C++, so I'm having 
a hard time interpretting ft2font.
If anyone can offer advice, I am a little desperate. Half of my plots are 
logscale, so I need to fix this in order to generate figures for my thesis. 
Is there anywhere I can look to learn the basics of dealing with fonts at 
this level? Any recommendations on C++ crash courses?
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...

>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...> writes:
 Scott> I routinely plot fairly large datasets (~4million
 Scott> points) using imshow but on my machine this takes
 Scott> about 11 secs to complete. I went through the code
 Scott> and made a couple of minor changes where the image
 Scott> data would get clipped by vmax and vmin only if the
 Scott> user supplied a vmax or vmin. The clipping is
 Scott> unnecessary if the user does not supply these values
 Scott> since vmax and vmin default to the max and min in
 Scott> the image. I also replaced two successive
 Scott> where(...) calls with a single clip(...) call and
 Scott> that seems to have helped a tiny bit as well. This
 Scott> change has been tested on 0.80 compiled with
 Scott> Numeric, though I can't envision how this would
 Scott> break anything. The profiler tells me that my plot
 Scott> time has decreased from 11.8 sec to 7.2 sec. Hope
 Scott> this helps.
Thanks Scott -- this simple optimization should help a lot with common
use cases. I've applied it in my local tree (hasn't made CVS yet
because there are other more significant changes I'm working on that I
can't commit yet).
Thanks!
JDH

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