matplotlib-devel Mailing List for matplotlib (Page 541)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
The debian package has a new address due to recent changes on mentors.debian.net.
Instructions for installing are now:
- --8<----------------------------------------------------------------------
* add this lines to your /etc/apt/sources.list:
 deb http://anakonda.altervista.org/debian packages/
 deb-src http://anakonda.altervista.org/debian sources/
* then run:
 # apt-get update
 # apt-get install python-matplotlib python-matplotlib-doc
- --8<----------------------------------------------------------------------
- --
/Vittorio Palmisano/
Home Page: http://redclay.altervista.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBHR2fpT6bvDtyXOIRAmEFAJ9+T6EHRTVksp2oapB2KwF6eB0KkQCgkQid
zNg2B1ZEoKTiFUPEKyFT9yk=
=mxaZ
-----END PGP SIGNATURE-----
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Telefonare all'estero risparmiando fino all'80%? Con Email.it Phone Card puoi, clicca e scopri tutti i vantaggi
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2683&d=13-8

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> OK. I made the changes that Darren Dale suggested and the
 Paul> plot now looks good.
Great, I take it you'll commit these to CVS....
 Paul> Done. The file is uploaded.
OK, thanks. I'll see if I can get any insight into the PS bug. It
may be, as you suggest, a line size issue. That looked like a pretty
dense spectrum you plotted.
If you were following the user list, Jin-chung found a pathological
case where the agg renderer runs out of ink for extremely long dense
paths that cover over 4 Mega-pixels with ink. His problem can be
solved by breaking up really long paths into separate paths (not
implemented yet). It may be that the same thing is needed in
backend_ps to accommodate gv.
JDH

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> 
> Paul> No, the latest CVS still shows the bug.
> 
> I haven't included his changes yet so you would have had to add the
> code yourself. I can take a look later though.
OK. I made the changes that Darren Dale suggested and the plot now looks good.
> >> Otherwise, if you can send me a tarball which has a script and
> >> some data so I can replicate the bug, I'll take a look. These
> >> bugs are easier to fix if you have something to test against.
> 
> Paul> Attached is the data (FITS) file and the following are the
> Paul> commands that I use to plot the data. You may need to
> Paul> download the pyfits module to access the file.
> 
> I don't think your data file came through properly. You may want to
> upload it to http://nitace.bsd.uchicago.edu:8080/files/share
Done. The file is uploaded.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> No, the latest CVS still shows the bug.
I haven't included his changes yet so you would have had to add the
code yourself. I can take a look later though.
 >> Otherwise, if you can send me a tarball which has a script and
 >> some data so I can replicate the bug, I'll take a look. These
 >> bugs are easier to fix if you have something to test against.
 Paul> Attached is the data (FITS) file and the following are the
 Paul> commands that I use to plot the data. You may need to
 Paul> download the pyfits module to access the file.
I don't think your data file came through properly. You may want to
upload it to http://nitace.bsd.uchicago.edu:8080/files/share
 Paul> Thanks for taking a look at this.
No problem...
JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> 
> Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
> Fernando> chokes on the file: CPU utilization goes to 100% after
> Fernando> displaying the axes, labels, and a tiny bit of the
> Fernando> graph. I killed it after a while.
> 
> I had the same problem with ggv (but I converted it with ps2pdf and
> viewed it as pdf). What are you using as a PS viewer Paul?
GGV (i.e. Gnome ghostview)
> One thing that concerns about embedding truetype fonts in PS figures
> is that they don't look very good in standard viewers (xdvi, ggv)
> though they seem to print fine, at least on the printers I've tried.
> It may be that the viewers don't have very good truetype rendering
> algorithms.
It might also be the standard fonts that we use. In other words, there might be 
other truetype fonts that render better with freetype2.
> I'm on the fence about whether we should revert to the afm fonts for
> plain text in PS, and just use truetype for mathtext and if
> explicitly requested using a yet-to-be-determined mechanism. These
> certainly look better in the PS viewers I've tried. Of course the
> truetype fonts offer the same look and feel across backends, which is
> why I am on the fence. Any opinions here?
I don't see a gain here, since PS output is mainly for printing where the fonts 
look fine. Maybe we should invest more effort in a PDF backend, which displays 
better in a viewer and also does the conversion to PS. Or switch to TTF that 
render better in a viewer, such as the core MS TT fonts.
> Fernando> Are there known problems with the Postscript generated
> Fernando> by matplotlib? Can it produce EPS directly (better for
> Fernando> publication)?
> 
> EPS: yes - just save as *.eps from just about any backend.
> 
> The only reported problem I've heard was a post from Flavio Coelho
> 
> While on the same topic, I had some problems inserting matplotlib
> generated PS plots into TeXMacs, although they open normally in gv,
> for instance. have you have seen any compatibility issues for the PS
> files and other PS viewing programs? Running ps2ps on the
> matplotlib PS files resolved the problem. However I wanted to use
> TexMacs as a frontend to use matplotlib interactively...
> 
> Paul, so we could help narrow this problem with gv and your figure,
> could you try generating it with 0.60.2 (which uses AFM if I recall
> correctly) to see if it is related to the new font handling in PS?
I'll take a look at it. However, I suspect the fonts are not the problem, since 
each font only increases the size of the PS file by about 60 kBs. I suspect it 
is the size of the data and the rendering code that is causing the problem.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
> 
> 
> Paul> I found a bug in the Y-axis scaling. See the attached PS
> Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in
> Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having
> Paul> experience with the scaling code want to fix this?
> 
> Darren Dale posted a small fix related to ticking for exponentially
> formatted data to the users list today - you may want to see if that
> helps.
No, the latest CVS still shows the bug.
> Otherwise, if you can send me a tarball which has a script and some
> data so I can replicate the bug, I'll take a look. These bugs are
> easier to fix if you have something to test against.
Attached is the data (FITS) file and the following are the commands that I use 
to plot the data. You may need to download the pyfits module to access the file.
 >>> import pyfits
 >>> from matplotlib.matlab import *
 >>> fits = pyfits.open('C05302010011alif4ttagfcal.fit')
 >>> data = fits[1].data.field
 >>> plot(data('wave'), data('flux'))
[<matplotlib.lines.Line2D instance at 0x40da5c4c>]
 >>> show()
Thanks for taking a look at this.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Well, I actually tried to see it but gv (Fedora Core 2)
 Fernando> chokes on the file: CPU utilization goes to 100% after
 Fernando> displaying the axes, labels, and a tiny bit of the
 Fernando> graph. I killed it after a while.
I had the same problem with ggv (but I converted it with ps2pdf and
viewed it as pdf). What are you using as a PS viewer Paul?
One thing that concerns about embedding truetype fonts in PS figures
is that they don't look very good in standard viewers (xdvi, ggv)
though they seem to print fine, at least on the printers I've tried.
It may be that the viewers don't have very good truetype rendering
algorithms.
I'm on the fence about whether we should revert to the afm fonts for
plain text in PS, and just use truetype for mathtext and if
explicitly requested using a yet-to-be-determined mechanism. These
certainly look better in the PS viewers I've tried. Of course the
truetype fonts offer the same look and feel across backends, which is
why I am on the fence. Any opinions here?
 Fernando> Are there known problems with the Postscript generated
 Fernando> by matplotlib? Can it produce EPS directly (better for
 Fernando> publication)?
EPS: yes - just save as *.eps from just about any backend.
The only reported problem I've heard was a post from Flavio Coelho
 While on the same topic, I had some problems inserting matplotlib
 generated PS plots into TeXMacs, although they open normally in gv,
 for instance. have you have seen any compatibility issues for the PS
 files and other PS viewing programs? Running ps2ps on the
 matplotlib PS files resolved the problem. However I wanted to use
 TexMacs as a frontend to use matplotlib interactively...
Paul, so we could help narrow this problem with gv and your figure,
could you try generating it with 0.60.2 (which uses AFM if I recall
correctly) to see if it is related to the new font handling in PS?
Thanks,
JDH

Paul Barrett wrote:
> Yes, I have the same problem with ggv. However, it prints fine on a PS printer, 
> so I think it's ghostview.
Mmh. It still might be worth looking into. Even if it's a ghostview problem, 
 it might be possible to generate 'friendlier' PS code that doesn't kill 
ghostview so badly. As people start using matplotlib for generating EPS plots 
which will go into papers, the "if you can't preview it just print it" answer 
is going to make quite a few unhappy campers, I suspect.
I know it sucks to code around the bugs of other code, but given that 
ghostview is the near-universally available tool (I checked the problem 
against RedHat 9, Fedora 1 and Fedora 2), matplotlib might want to bow a bit 
in this case :)
Just a suggestion.
Best,
f

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:
 Paul> I found a bug in the Y-axis scaling. See the attached PS
 Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in
 Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having
 Paul> experience with the scaling code want to fix this?
Darren Dale posted a small fix related to ticking for exponentially
formatted data to the users list today - you may want to see if that
helps.
Otherwise, if you can send me a tarball which has a script and some
data so I can replicate the bug, I'll take a look. These bugs are
easier to fix if you have something to test against.
JDH
 Paul> For those interested, this is a section of the far
 Paul> ultraviolet spectrum of the variable star SS Cygni (SS Cyg
 Paul> for short) taken by NASA's Far Ultraviolet Spectroscopic
 Paul> Explorer (FUSE for short).
 Paul> -- Paul
 Paul> -- Paul Barrett, PhD Space Telescope Science Institute
 Paul> Phone: 410-338-4475 ESS/Science Software Branch FAX:
 Paul> 410-338-4767 Baltimore, MD 21218

Paul Barrett wrote:
> I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis 
> scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is 
> zeros. Anyone having experience with the scaling code want to fix this?
> 
> For those interested, this is a section of the far ultraviolet spectrum of the 
> variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
> Spectroscopic Explorer (FUSE for short).
Well, I actually tried to see it but gv (Fedora Core 2) chokes on the file: 
CPU utilization goes to 100% after displaying the axes, labels, and a tiny bit 
of the graph. I killed it after a while.
Are there known problems with the Postscript generated by matplotlib? Can it 
produce EPS directly (better for publication)?
Cheers,
f

I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis 
scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is 
zeros. Anyone having experience with the scaling code want to fix this?
For those interested, this is a section of the far ultraviolet spectrum of the 
variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet 
Spectroscopic Explorer (FUSE for short).
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

John Hunter wrote:
> What's new in matplotlib-0.61.0 - 
> * You can put a .matplotlibrc file in a dir to override the one in
> your HOME dir. If you have a project, say a book, and you want to
> make a bunch of images with the same look and feel for the book,
> you can place a custom rc file in the code dir for that book and
> this won't affect the configs you use for normal, interactive use.
Just a question/suggestion on this. Is there any user-available function to 
load matplotlibrc files? Instead of relying on .files (hidden from normal ls 
calls), it would be nice if _any_ file could live in a directory defining this 
configuration. One could then in a script for a specific project write:
load_rc('myproject_matplolibrc')
...
This would even allow you to cleanly maintain multiple rc files in the same 
directory, in case you want. I also think it serves better the 'explicit is 
better than implicit' python mantra: I'd even prefer NOT to have silent 
loading of .matplotlibrc files beyond that in ~/, since this would mean that 
matplotlib will behave differently depending on where you start it. I think 
this can be confusing.
Just having an available loadrc() routine would solve the surprise issue, 
allow multiple rc files per directory (for interactive and publication work, 
for example), and the user cost would remain minimal: just a simple function 
call to do the loading.
Just some ideas...
Best,
f

What's new in matplotlib-0.61.0 - 
 Note win32 pygtk users - if you encounter problems or errors related
 to svg loading, see note at end of this email.
You can read these announce notes in html with hyperlinks at
http://matplotlib.sf.net/whats_new.html.
 * A new, enhanced, navigation toolbar. Set 'toolbar : toolbar2' in
 matplotlibrc to try it out. Tutorial on the new toolbar is at
 http://matplotlib.sf.net/tutorial.html#toolbar2. Note that this
 toolbar behaves very differently than the classic toolbar. To use
 it, you must click on the pan/zoom or zoom to rect and then
 interact with the axes by dragging your mouse over it. The
 'forward', 'back' and 'home' buttons are used to navigate between
 previously defined view limits. At some point we'll add multiple
 simultaneous axes support for the new toolbar but we're still
 mulling over the interface - if you need it you can still uses
 toolbar : classic.
 * Mathtext for PS!!! Also, PS now embeds TrueType fonts so the same
 fonts you use in the *Agg GUIs should be displayed in PS
 output. Thanks Paul Barrett!
 * The imread function is used to load PNGs into arrays. I'd like to
 add more image loaders and savers down the road -
 http://matplotlib.sourceforge.net/matplotlib.matlab.html#-imread
 * New event handling. The functions mpl_connect and mpl_disconnect
 are used for backend independent event handling. The callback
 signature is func(event). See
 http://matplotlib.sf.net/tutorial.html#events and
 http://matplotlib.sf.net/examples/coords_demo.py. The new events
 carry lots of useful information in them, like the coords in
 display and data units, the axes instance they were over, keys
 pressed during the event and more.
 * Many fixes to the SVG backend, including page layout, font support
 and image support. SVG is now considered alpha. You can save
 ps/eps/svg figures from GUI backends by providing the right
 extensions. SVG is currently the fastest backend in my tests.
 * More memory leaks fixed - see
 http://matplotlib.sourceforge.net/faq.html#LEAKS for details. My
 estimate is that complex figures (multiple subplots, images, etc..)
 now leak no more than 10-50 bytes per figure. Down from several
 hundred bytes per figure in 0.60.
 * Vertical mathtext in backend_agg (ylabels now work properly!).
 mathtext with arbitrary rotations in PS. Thanks Jim Benson and
 Paul Barrett!
 * Added some abbrev functions in matplotlib.lines, mainly for
 interactive users trying to save key strokes. markerfacecolor is a
 lot of keys! For lines, these abbrevs were added
 aa : antialiased
 c : color
 ls : linestyle
 lw : linewidth
 mec : markeredgecolor
 mew : markeredgewidth
 mfc : markerfacecolor
 ms : markersize
 Thus you can type --not necessarily recommended for readability in
 scripts or apps but great for throwaway use in interactive shells
 
 # no antialiasing, thick green markeredge lines
 >>> plot(range(10), 'ro', aa=False, mew=2, mec='g')
 Analogs in matplotlib.patches
 aa : antialiased
 lw : linewidth
 ec : edgecolor
 fc : facecolor
 * You can put a .matplotlibrc file in a dir to override the one in
 your HOME dir. If you have a project, say a book, and you want to
 make a bunch of images with the same look and feel for the book,
 you can place a custom rc file in the code dir for that book and
 this won't affect the configs you use for normal, interactive use.
 * Updated installing instructions at
 http://matplotlib.sf.net/installing.html (see also INSTALL in src
 distro). Fixed a tk/osx install problem in setupext.py
 * New demo for wx/wxagg showing how to to make a flicker free cursor
 that follows the mouse and reports the coords in a status bar - see
 http://matplotlib.sf.net/examples/wxcursor_demo.py
 * Numerous bug fixes and minor enhancements detailed at
 http://matplotlib.sf.net/CHANGELOG
Downloads at http://sourceforge.net/projects/matplotlib
pygtk / win32 bug
 Alas, an enterprising matplotlib user found a bug in matplotlib-0.61
 on win32 with recent versions of pygtk even before the announcement.
 Sigh. Is it just me or is testing multiple GUIs with multiple,
 incompatible versions on multiple platforms a pain? 
 Apparently this bug is only exposed on recent versions of pygtk for
 win32. If you encounter problems, try removing or commenting out
 the last lines of site-packages\matplotlib\backends\backend_gtk.py
 which set the matplotlib minimization icon. Eg, triple quote
"""
# set icon used when windows are minimized
if gtk.pygtk_version >= (2,2,0):
 basedir = matplotlib.rcParams['datapath']
 fname = os.path.join(basedir, 'matplotlib.svg')
 try: gtk.window_set_default_icon_from_file (fname)
 except gobject.GError, exc: print >>sys.stderr, exc
"""

I've added some of the features discussed on this list to the
navigation framework:
 * events now have a key attribute: an ascii char | 'control' |
 'shift' | 'alt'. I yet haven't exposed key_press_event to
 mpl_connect though this isn't much more work. I did this
 primarily so I could find out if 'x', 'y' or 'control' were
 pressed during pan/zoom right click events. As discussed before,
 these three modifiers constrain the interactive zoom to x only, y
 only or proportion constrained. I also am not currently handling
 key presses with modifiers but this is only a but more work - this
 can wait until key press is exposed through the mpl_connect
 interface.
 * dynamic update - an optional method dynamic_update refreshes the
 canvas during the navigation mouse move event. 
 * rubber banding - a visual rectangle using native drawing for zoom
 to rect. Optional method is draw_rubberband.
All of the above are implemented in wx* and gtk* in CVS.
The major outstanding issue re navigation is multiple axes selection.
Still ruminating.... 
I'd like to get all this wrapped up by next week if possible for 0.61.
There are some fairly important bugs in the last release (notably the
wxagg segfault on window resize) as well as nifty new features since
then (toolbar2, svg fixes, ps mathtext!!) that should be roaming free
in the while rather than caged up in CVS.
JDH

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:
 Stefan> Hi, I upgraded to libpng v1.2.5 from v1.0.14. ( on a
 Stefan> linux box, using Agg backend and matplotlib v0.54.2 ) Now
 Stefan> I get this Runtime error thrown at _backend_agg.cpp line
 Stefan> 948
 Stefan> png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING,
 Stefan> NULL, NULL, NULL); if (png_ptr == NULL) { fclose(fp);
 Stefan> throw Py::RuntimeError("could not create write struct");
 Stefan> }
 Stefan> Has anyone seen this?
I just tried a built both matplotlib 0.54.2 and CVS against
libpng1.2.5 and was able to save an agg png w/o incident. Make sure
you are not getting old png headers, have a clean matplotlib build,
run ldconfig, etc...
JDH

Hi,
I upgraded to libpng v1.2.5 from v1.0.14. ( on a linux box, using Agg
backend and matplotlib v0.54.2 ) Now I get this Runtime error thrown
at _backend_agg.cpp line 948
png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING, NULL, NULL,
NULL);
 if (png_ptr == NULL) {
 fclose(fp);
 throw Py::RuntimeError("could not create write struct");
 }
Has anyone seen this?
thanks,
Stefan
	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I viewed matplotlib.svg in gqview (on Linux) and it looks
 Steve> like the icon image only uses about two thirds of the svg
 Steve> width and height, so the minimize icon ends up being too
 Steve> small.
Indeed. I fixed this in CVS (and a number of other fixes for SVG
including some layout problems, image support and font support).
There appears to be a problem with the svg lib gnome uses. For one
thing, the axes appear black even though the hex code is #ffffff.
This does not happen in mozilla with the adobe plugin or with batik.
It appears GNOME uses the same lib (unsurprisingly) because when I
minimize the figure I also get the black axes background.
JDH

On Tue, 2004年07月27日 at 04:36, John Hunter wrote:
> 
> I had the bright idea to use the svg backend to generate the
> minimization icon. See examples/matplotlib_icon.svg. It displays
> correctly on my web browser, but not when minimized. I don't know if
> this reflects a problem in the svg backend, or how gtk handles svg
> icons.
> 
> If we can get this example to work, the next thing to do is connect
> the icon setting to the window minimize event, and set the icon to be
> the svg output of the current figure window!
> 
> JDH
I viewed matplotlib.svg in gqview (on Linux) and it looks like the icon
image only uses about two thirds of the svg width and height, so the
minimize icon ends up being too small.
Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> I've added an icon for use for when matplotlib windows are
 Steve> minimized and chose an arbitrary icon (back.svg) to get it
 Steve> working on the GTK+ backend. Since the icon has to be
 Steve> resized to fit in the panel, and svg are good at resizing,
 Steve> I used svg instead of the usual png format (png or other
 Steve> formats could be used instead if required).
 Steve> John, if you can find/create a suitable matplotlib icon
 Steve> just copy it to images/matplotlib.svg and overwrite the
 Steve> existing icon file.
I had the bright idea to use the svg backend to generate the
minimization icon. See examples/matplotlib_icon.svg. It displays
correctly on my web browser, but not when minimized. I don't know if
this reflects a problem in the svg backend, or how gtk handles svg
icons.
If we can get this example to work, the next thing to do is connect
the icon setting to the window minimize event, and set the icon to be
the svg output of the current figure window!
JDH

> -----Message d'origine-----
> De : mat...@li...=20
> [mailto:mat...@li...] De la=20
> part de John Hunter
> Envoy=E9 : lundi 26 juillet 2004 21:26
> =C0 : mat...@li...
> Objet : [matplotlib-devel] constrained zoom
>=20
>=20
>=20
> One more thought on interactive zoom. As I was trying out=20
> the interactive zoom (not zoom to rect, but right click on=20
> pan zoom) on some image data, I noticed that it would be=20
> useful to have some constraints on the zoom
>=20
> - zoom only on x. Already the x zoom is determined by the amount of
> movement in the horizontal direction, but it would be nice to be
> able to ignore the y direction. Candidate key modifier: 'x'
>=20
> - zoom only on y. ditto. Candidate key modifier: 'y'
>=20
> - preserve axes aspect ratio. Candidate key modifier: ??. I think
> some apps use a SHIFT or a CTRL modifier for this. Is there any
> consensus or common practice?
Yes, this will be very usefull! Add the group of axis (all of them react
to pan/zoom/zoom_to_rect of any of them, and it would be the ultimate
plot navigation tool :-) I go for shift for the last one (could even do
the 3 in one, kind of like power point snap to grid, except grid would
be 0/45/90 direction. I think powerpoint and many drawing program (adobe
illustrator, corel draw) act like that :-)

One more thought on interactive zoom. As I was trying out the
interactive zoom (not zoom to rect, but right click on pan zoom) on
some image data, I noticed that it would be useful to have some
constraints on the zoom
 - zoom only on x. Already the x zoom is determined by the amount of
 movement in the horizontal direction, but it would be nice to be
 able to ignore the y direction. Candidate key modifier: 'x'
 - zoom only on y. ditto. Candidate key modifier: 'y'
 - preserve axes aspect ratio. Candidate key modifier: ??. I think
 some apps use a SHIFT or a CTRL modifier for this. Is there any
 consensus or common practice?
JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> *zoom out to rect is implemented, works ok but is not as
 Gregory> intuitive as I hoped (interrective pan/zoom is so good
 Gregory> that it will be seldom used, I guess ;-) ). After
 Gregory> testing it, I guess an interractive Pan/Zoom with
 Gregory> shift_key
 pressed-> zoomx=zoomy would be a worthier extension
I say we drop it then. Obviously you are free to do what you want on
your backend, but it doesn't sound like it adds enough to incorporate
it into the general framework.
 Gregory> However, doing these modif I had some small problems:
 Gregory> -it seems current CVS print ticker locator instances at
 Gregory> redraw, I think since you corrected some ticker locator
 Gregory> bug or something...very minor I guess 
Fixed, thanks
 Gregory> the intended goal...I do not know why, as the axes
 Gregory> instance a printed continuously during the drag, showing
 Gregory> that figure is redrawed...but it shows to the screen only
 Gregory> when I release the button :-(
...snip 
 Gregory> -Why is the screen updated only after button release? Is
 Gregory> there an extra operation to do except the draw, is screen
 Gregory> updating blocked during events (maybe a double
 Gregory> buffering?) ...Or I am doing something forbidden
 Gregory> re-assigning callbacks within another callback?
The reason was performance. tk blits slowly do it is hard to get
interactive refresh rates. Also, matplotlib can be slow for some
figures, so I didn't want to bod down performance with interactive
redraws. 
In retrospect, I think it is a good idea to support dynamic updates.
I recoded the navigation toolbar base class a bit to call a method
dynamic_update during pan/zoom mode and implemented this for gtk (not
yet wx). It is a *very nice* feature, IMO. I had to trap the button
press and release events in gtk because button wasn't defined on a
drag (I guess this is the purpose of a drag event :-). My preference
for now is to not add a separate drag event to mpl_connect for
simplicity, but I'm open to it if you and the rest of the gang think
we should. We can always add it later.
Todd, you may want to take a stab at implementing this in tkagg --
you'll like it! For the slower interactive backends (wx*, tk) it may
be a good idea to make the dynamic update an rc param.
JDH

Hi John,
I have modified the fltk backend for toolbar2 and I am now quite happy
with it's capabilities:
*Zoomtorect and pan/zoom are toggle buttons, that can be
activated/pushed or deactivated/raised
Push on zoomtorect de-activate pan/zoom and vice-versa, and when none
are activated one go back to initial situation (just the default
pointer, no action (ideal would be to cache the callback associated to
motion, push and release, so that one can go back to user-defined
behavior)
*rubber band is drawed during zoom_to_rect
*motion_notify event is captured, i.e. pointer shape change when it
enter axes if Pan/zoom or zoom_to_rect is active
*pan/zoom is interractive, i.e. view is refreshed continuously when user
drag the mouse keeping the button pushed (speed is ok, same as window
resize)
*zoom out to rect is implemented, works ok but is not as intuitive as I
hoped (interrective pan/zoom is so good that it will be seldom used, I
guess ;-) ).
After testing it, I guess an interractive Pan/Zoom with shift_key
pressed->zoomx=zoomy would be a worthier extension
However, doing these modif I had some small problems: 
 -it seems current CVS print ticker locator instances at redraw, I think
since you corrected some ticker locator bug or something...very minor I
guess
 -my first implementation of interractive pan/zoom was by defining a
drag event: fltk is able to distinguish between a motion notify event
(mouse move, no button pressed) and a button_drag event (mouse move with
a button(s) pressed). This allows very clean and simple implementation,
but when I tried to extend it to GTKAgg I was in trouble: it seems there
is not 2 events generated, but that motion_notify have just the number
of the button pressed (or None)...
I emulated this in FltkAgg, collapsing the 2 events in one, and hacked
an interractive pan/zoom over it but it is not as clean as the previous
solution (change the mouse_move callback to pan_drag callback in
pan_press, go back to mouse_move at pan_release)...A little extra
benefit compensating for this is that the pointer stay a hand even if
one go outside the window, and I autorized it for extra freedom in
pan/zoom...
Problem is that this do not allow me to port interrative Pan/Zoom to
TkAgg or GTKAgg, which was the intended goal...I do not know why, as the
axes instance a printed continuously during the drag, showing that
figure is redrawed...but it shows to the screen only when I release the
button :-(
So I have 2 questions:
-What do you think is the best event model: 
Separate events for DRAG/MOTION, or same one and use button info for
differenting the 2? The second one (=current implementation) is simpler
and cleaner in the sense that we have less events, but on the other hand
in practive I guess one will often want to redefine the drag without
changing motion, and in this case the 2 event is cleaner...Well, of
course if there is no simple way to generate 2 event except in fltk,
better to stay with 1 event for portability...
-Why is the screen updated only after button release? Is there an extra
operation to do except the draw, is screen updating blocked during
events (maybe a double buffering?) ...Or I am doing something forbidden
re-assigning callbacks within another callback?
Best regards,
Greg.
PS: still no news from pyfltk guy nor any activity on the pyfltk list :(

I've added an icon for use for when matplotlib windows are minimized and
chose an arbitrary icon (back.svg) to get it working on the GTK+
backend. Since the icon has to be resized to fit in the panel, and svg
are good at resizing, I used svg instead of the usual png format (png or
other formats could be used instead if required).
John, if you can find/create a suitable matplotlib icon just copy it to
images/matplotlib.svg and overwrite the existing icon file.
Regards,
Steve

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
 Gregory> Done...I used the relief method, it is probably more
 Gregory> portable across guis and use less screen estate. But
 Gregory> idealy a second push to the button should de-activate the
 Gregory> respective action (i.e. toggle mode), is this done in the
 Gregory> current CVS? Well, best way to know is to checkout ;-)
This should be handled exclusively on your end, eg by binding
'pan/zoom' button press to a wrapper function which does the gui
settings and then calls NavigationToolbar2.pan.
 >> I updated the way the pointer setting calls in CVS. Now you
 >> only get the special pointers when you are over an axes -
 >> otherwise you get the arrow pointer. I did this by connecting
 >> to the motion_notify_event.
 Gregory> Oups! This is good, but it make me realise I did not
 Gregory> understand the motion_notify_event, it mistake it for
 Gregory> drag event... Well, both are interresting, how about
 Gregory> adding some events? For now I have: button_press_event
 Gregory> button_release_event key_press_event key_release_event
 Gregory> *button_drag_event *button_double_press_event and I need
 Gregory> to add motion_notify_event
Not sure we need draw since we effectively implement everything with
press/ move/ mouse. The others would be good. The Event class /
interface for key press events needs to be determined. It would be
nice to support modifier keys. Feel free to take a stab at
implementing this in backend_bases. double_click would also be
worthwhile.
 >> I would like to have this on all the backends ideally. I could
 >> make a call from the NavigationToolbar2 -
 >> set_zoom_overlay(xmin, xmax, ymin, ymax) from the motion event.
 >> Would this help you? Todd , Steve, do you know how to do this
 >> in your respective backends? Theoretically, it could be done
 >> using matplotlib lines, but then the canvas would have to be
 >> redrawn and reblitted dynamically and I don't think the
 >> performance is good enough for that in most cases, especially
 >> for Tk which is slow for this kind of thing. Is there a native
 >> GUI solution for this on the respective backends?
I added a few new (optional) methods to support the zoom to rectangle
bounding box, aka rubber band. I implemented this in wx and gtk using
native drawing so they are fast enough. The new methods are
 * draw_rubberband (optional) : draw the zoom to rect
 "rubberband" rectangle
 * press : (optional) whenever a mouse button is pressed, you'll be
 notified with the event
 
 * release : (optional) whenever a mouse button is released,
 you'll be notified with the event
 Gregory> Hum, the overlay problem is already solved for fltk
 Gregory> (although it is not so clean for the moment, it is done
 Gregory> between the fltk event interception and the event
 Gregory> conversion in MplEvent...)It use native fltk blitting, so
 Gregory> no redraw is involved, so you can consider it fully
 Gregory> solved on fltk...
You may want to consider fitting this into the above framework, if
possible.
 Gregory> I called it Pan/Zoom (how original ;-) ). Reagrding my
 Gregory> reverse zoom, in fact it have the same relationship with
 Gregory> right click for zoom out, than zoom to rectangle has to
 Gregory> the right click for zoom in: the 2 are similar and can
 Gregory> perform the same operation, but in a different manner
 Gregory> (right click with pan/zoom center operation on clicked
 Gregory> point, then interractively (well, in the future ;-) )
 Gregory> zoom in/out, while zoom_to_rect is not interractive, the
 Gregory> user select the new zone that will be expaned to window
 Gregory> (zoom in as it is) or that the window will occupy (new
 Gregory> zoom out to rectangle)...Both can be used depending on
 Gregory> the situation and the user preference...
Looks a little like unnecessary complexity (still don't really
understand it) to me, but if you want to implement prototype, eg for
fltk, I'll be happy to take it for a test drive later.
Thanks,
JDH