Hi, I'm in the way of rewriting in Python from scratch an old matlab data analysis program for AFM data. The program should have a quite simple GUI with a graph capable of interactive plotting (i.e. clicking on two points on a 2d graph and fitting the points in between) and a couple of buttons/menus for fit options and graph options. It's a couple of days I'm learning matplotlib/pylab and scipy, and they seem powerful enough to fulfill my needs. Now, my dream would be to embed matplotlib in a full WxPython application, instead of using pylab, but (1)I have read that it requires to rewrite some basic pylab facilities, like taking plot coordinates of the mouse, that I really need and that's very easy to use (2)I still have to learn WxPython, and even if I'd eventually do it, it seems messy to me to learn WxPython and to embed matplotlib in it at the same time (3)I have not so much time...I have to analyze that data, more sooner than later. :( I think I'll eventually do an embedded matplotlib application, but I'd like to think about it as "version 2.0". So, there are two solutions that I'm considering: - Using WxMpl or MPlot. What are pros and cons of both wrappers? - Creating a small, pure WxPython application that calls pylab to manage graph operations. I think it would look somehow like Gimp, with a tall and thin window full of buttons, menus etc. and the graph as a separate pylab window. What's the best alternative and/or your advice and critics about it? Thanks, Massimo -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
massimo sandal wrote: > Now, my dream would be to embed matplotlib in a full WxPython > application, instead of using pylab That is probably a good way to go. > but (1)I have read that it requires to rewrite some basic pylab facilities As any of us write them, we need to contribute them back to MPL, so that one day, everything will be in the OO interface. there will always be a couple extra things, like managing where to put your MPL window, but you'd want to control that anyway in an embedded app. > It seems messy > to me to learn WxPython and to embed matplotlib in it at the same time You are right that that is a bit of a project. > So, there are two solutions that I'm considering: > - Using WxMpl or MPlot. I would say to use one of these for sure. > What are pros and cons of both wrappers? I'd love to see this too. It would be great if we could standardize on one, full featured, wxMPL solution. > - Creating a small, pure WxPython application that calls pylab to manage > graph operations. The issue is that pylab expects to manage it's own Frame. You can't have two wxPython applications in one process, so they will collide, unless you are talking about running a pylab instance in a separate process. That would require some kind of inter-process communication, which would be more work than figuring out how to embed MPL in wx. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Chris, >> but (1)I have read that it requires to rewrite some basic pylab >> facilities > > As any of us write them, we need to contribute them back to MPL, so that > one day, everything will be in the OO interface. there will always be a > couple extra things, like managing where to put your MPL window, but > you'd want to control that anyway in an embedded app. I'd surely love to contribute to free software. I'll probably hack something to cover my needs, but I think contributing back would need to have things polished and coherent. I don't know if I will manage to do it... Anyway I'll release all my software publicly under a free license (GPL probably), and if I put up something of interest for MPL, I will be happy to discuss it on the MPL-devel mailing list. About the OO MPL interface, it seems to be a bit lacking in documentation. Is there some hint you can give me? What important goodies pylab has that the OO interface has not? I'm expecially concerned about the rectangular zoom and mapping the mouse position on the plot, I have quite a need for them. >> It seems messy to me to learn WxPython and to embed matplotlib in it >> at the same time > > > You are right that that is a bit of a project. Well, I had a look to the wxpython tutorial in the meantime and happily it looks easier than I thought before. I have already played with Tkinter in the past and the underlying logic seems similar. So perhaps it's not so bad, I'll play a bit with wxpython at home to see how comfortable I am. >> So, there are two solutions that I'm considering: >> - Using WxMpl or MPlot. > > I would say to use one of these for sure. > >> What are pros and cons of both wrappers? > > I'd love to see this too. It would be great if we could standardize on > one, full featured, wxMPL solution. Hope someone will give us suggestions about these libraries. I'm not that happy to add another dependency to my project, but reading below it seems the only way to go. >> - Creating a small, pure WxPython application that calls pylab to >> manage graph operations. > The issue is that pylab expects to manage it's own Frame. You can't have > two wxPython applications in one process, so they will collide, unless > you are talking about running a pylab instance in a separate process. > That would require some kind of inter-process communication, which would > be more work than figuring out how to embed MPL in wx. Ok. This is a bit bad, because it seemed the simplest solution. I thought that the pylab frame and the wxapp frame could be kept distinct but interacting in the same app, just being two separate objects. Thank you a lot, you saved me a lot of time! Massimo -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
>>>>> "massimo" == massimo sandal <mas...@un...> writes: massimo> About the OO MPL interface, it seems to be a bit lacking massimo> in documentation. Is there some hint you can give me? There is some tutorial documentation, particularly Robert Leftwich's tutorial - http://matplotlib.sourceforge.net/leftwich_tut.txt. This link recently disappeared (by accident) from the FAQ entry http://matplotlib.sf.net/faq.html#OO massimo> What important goodies pylab has that the OO interface massimo> has not? I'm expecially concerned about the rectangular massimo> zoom and mapping the mouse position on the plot, I have massimo> quite a need for them. I would humbly suggest that the difficulty of the OO interface is overstated. There is almost nothing in the pylab interface -- all of it is a wrapper of the OO code. With the exception of figure management, of course, which you don't want to use in an app anyway. Consider the canonical OO example from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas from matplotlib.figure import Figure fig = Figure() canvas = FigureCanvas(fig) ax = fig.add_subplot(111) ax.plot([1,2,3]) ax.set_title('hi mom') ax.grid(True) ax.set_xlabel('time') ax.set_ylabel('volts') canvas.print_figure('test') As for interaction, you can do all the panning, zooming, toolbaring, whatevering you want from the OO interface. Just connect to the events you want with canvas.mpl_connect if you want to use matplotlib's event handling, and you can use ax.pick if you want to pick actors. For examples on using events, search the examples dir for "connect" > grep -l "connect(" *.py | xargs ls animation_blit_fltk.py embedding_in_qt.py picker_demo.py coords_demo.py gtk_spreadsheet.py poly_editor.py cursor_demo.py interactive2.py pylab_with_gtk.py embedding_in_gtk2.py keypress_demo.py strip_chart_demo.py embedding_in_gtk3.py mpl_with_glade.py toggle_images.py embedding_in_gtk.py object_picker.py wxcursor_demo.py As you can see there are a couple of wx specific examples. One nice thing about using mpl event handling instead of native wx handling is that the examples will work unchanged across GUIs, so you can plug these examples directly into your wx app. Just use "canvas.mpl_connect" instead of the pylab "connect" JDH
On 11/30/05 11:50, Chris Barker wrote: > massimo sandal wrote: >> Now, my dream would be to embed matplotlib in a full WxPython >> application, instead of using pylab > > That is probably a good way to go. I also agree that this is the way to go. If you're going to be putting a lot of effort into the rest of the application, I'd encourage you to go the extra mile and embed matplotlib rather than using pylab. If nothing else, the result will have a more consistent and polished look. >> but (1)I have read that it requires to rewrite some basic pylab >> facilities If you just embed a FigureCanvasWxAgg you're going to have to write all of the user interaction stuff, like zooming. If you use one of the embedding libraries you get all of that for free. > As any of us write them, we need to contribute them back to MPL, so that > one day, everything will be in the OO interface. You're right, Chris. The only problem is that I see some tension between providing a decent OO API in matplotlib and providing good support for embedding. For example, in WxMpl I chose to favor wxPython's event system over matplotlib's events because I felt it made for a more consistent API for wxPython programmers. >> - Creating a small, pure WxPython application that calls pylab to >> manage graph operations. > > The issue is that pylab expects to manage it's own Frame. You can't have > two wxPython applications in one process, so they will collide, unless > you are talking about running a pylab instance in a separate process. The problem isn't pylab managing its own wx.Frame, but rather that Pylab used to always try to create its own wx.App. It now checks to see if one already exists, so you can to use pylab from your wxPython application without everything blowing up. Ken
Ken McIvor wrote: > You're right, Chris. The only problem is that I see some tension > between providing a decent OO API in matplotlib and providing good > support for embedding. For example, in WxMpl I chose to favor > wxPython's event system over matplotlib's events because I felt it made > for a more consistent API for wxPython programmers. Hmm. I'm a longtime user of wxPython, and an occasional user of MPL. Given the kind of work I do, it's only a matter of time before I need to embed MPL in wxPython. So I've been keeping an eye on your work, but not really using it. However, I'd love to have a nice natural way to use MPL in wx, and WxMPL seems to be designed just for that. I think I probably agree with you that using the native wx events make sense. I can imagine a lot of ways in which one would want to integrate MPL-related events with other parts of the application. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
On 11/30/05 12:29, massimo sandal wrote: > About the OO MPL interface, it seems to be a bit lacking in > documentation. Is there some hint you can give me? The EmbeddingInWx cookbook entry includes some good starting points: http://www.scipy.org/wikis/topical_software/EmbeddingInWx#ooapi It links to a bunch of matplotlib examples translated to the OO API: http://www.scipy.org/wikis/topical_software/oo-demos.py > What important goodies pylab has that the OO interface has not? I'm > expecially concerned about the rectangular zoom and mapping the mouse > position on the plot, I have quite a need for them. The most important difference is that pylab gives you user interaction features (like zooming and displaying the position) but the OO interface does not. An embedding library will give you those features, plus ones which pylab does not (e.g. printing support, selecting points and regions). > Hope someone will give us suggestions about these libraries. It's kind of an apples to oranges comparison, because WxMpl and MPlot attempt to solve different problems. MPlot gives you a very high-level interface for creating X/Y plots. WxMpl gives you smarter FigureCanvasWxAgg which can plot anything using matplotlib's OO API. Since your first email mentioned wanting to pick regions of a plot to fit over, I'd suggest trying out WxMpl. I just released a new version which fixes the point and region picking and includes a demo of it. Ken
>>>>> "Ken" == Ken McIvor <mc...@ii...> writes: Ken> The most important difference is that pylab gives you user Ken> interaction features (like zooming and displaying the Ken> position) but the OO interface does not. Not technically right, because the OO interface provides the FigureCanvasWX* and the NaviationToolbar2WX* which you can use to get all the interaction of the pylab interface. Eg embedding_in_wx.py. That said, I'm sure your wx embedding libs add lots of useful functionality so that is where I would look if starting out writing a wx app... JDH
On 11/30/05 15:39, John Hunter wrote: > Not technically right, because the OO interface provides the > FigureCanvasWX* and the NaviationToolbar2WX* which you can use to get > all the interaction of the pylab interface. Eg embedding_in_wx.py. Thanks John. I had completely about the NavigationToolbar, which is certainly an option. Ken
Massimo, You've gotten a lot of good pointers and advise from others. massimo sandal wrote: > I'll play a bit with wxpython at home to see how > comfortable I am. Be sure to join the wxpython-users mailing list. They (We) are every bit as helpful as this group. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
> If your immediate need is to analyze data and produce plots, take a > look at > the R statistical language or the Gri plotting system. Both are shorter > paths > to a solution of analyzed and plotted data. Ehm, no. I switched to Python just because I need more than simply this. What I described is the *main* thing my application must do, but we need an integrated app that, for example, loads and converts data from the instrument application file format, can save it in another format, can save data stats, produce illustrations, interface with the operating system and so on. I'm sure other packages can deal with it, but I feel Python has a much cleaner and complete interface for this all. Our data analysis is quite complex and requires automatization of a lot of tasks. We must deal with a LOT of data and keep them and their results automatically organized. We even need a basic plugin architecture, probably (quite complex here to explain why). We were used to solve it all with a bunch of Matlab scripts but they quickly become unmanageable. I could rewrite them in Matlab (I wouldn't like it for license reasons, but I can deal with it...) (or Octave, or Scilab) but (1)Matlab is very good at math/plots, and has excellent interactivity but s**ks when applied to other needs (2)I am quite comfortable with Python, although it's a lot I don't seriuosly code in it; I would have to learn R or Gri or Scilab basics instead (3)We need elegant, readable code that can be used and extended by many: me and most of my collegues know or at least can easily learn Python, and figuring out Python is really easy. Nevertheless, I promise I'll have a look to R and Gri, but I tested scipy and matplotlib these days, and I'm pretty convinced they are the way to go. Note that, despite I like Python very much, I was really skeptical before actually trying these two packages, so it's not fanboying. Massimo -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
Hello Massimo, > I'm in the way of rewriting in Python from scratch an old matlab data > analysis program for AFM data. The program should have a quite simple > GUI with a graph capable of interactive plotting (i.e. clicking on two > points on a 2d graph and fitting the points in between) and a couple of > buttons/menus for fit options and graph options. It's a couple of days > I'm learning matplotlib/pylab and scipy, and they seem powerful enough > to fulfill my needs. First of all, why not take a look at an existing solution for AFM: http://gwyddion.net/ It looks very good and is already very mature. It provides a plugin architecture, a modern graphical interface, is portable and seems to be funded as well. However, it can only analyze surface data, and I don't know if this is what you meant with '2d graph'. Best regards, Niklas Volbers.
Dear Massimo,
Sorry I wasn't able to respond sooner. I've been running experiments
all day. As a warning, this response may be long, and I won't take
the time to be overly polite. So let me say it now: Matplotlib is a
great plotting library and John should be knighted.
I was in a similar dilemma a little over a year ago when I was
comfortable enough with matplotlib and its development that I knew it
was what I wanted to commit to using. At that time (late summer
2004), wxmpl did not exist and many of the additions for interactivity
in matplotlib did not exist. I had already decided to abandon
Tkinter/Pmw.BLT plotting, but it took awhile to find a better
solution. Matplotlib is it.
And I definitely wanted (and still want) a wxPython plotting widget
which is intended to go into applications. Much of matplotlib, and
the other responses seem to fail to understand this: I (and I'm
assuming you) want a plotting widget that goes into a wxPython
application. I want to say something not much harder than
plotpanel =3D SomeMatplotLibPanel(wx_parent_id)
plotplanel.plot(x,y)
And then have the user (that is *MY* user -- the person running the
program, not the person writing the script) be able to change the
color, change the titles, zoom in, zoom out, print, save to a PNG.
MPlot tries to do this. For 2-d line plots, it does this fairly well.
It may not be the best code, it certainly could use improvement.=20
Please feel free to make or suggest changes. If you (or anyone else)
would like to use it or develop it, please let me know how I can help
you. I'd love for it to be improved -- it really needs false color
maps soon. OTOH, if something better comes along, I'll happily use
it.
Pylab is NOT suitable for applications. It assumes that the end user
is someone who uses python. Somehow this became the higher priority
for matplotlib. I think this is a terrible mistake. Seeing so many
examples and questions on this mailing list assuming
from pylab import *
is really quite sad. To me it suggest this lovely packaged advertised
as a library is not being used as a library at all. Matplotlib is far
too nice to be an add-on to IPython or used only for writing
quick-n-dirty scripts.
wxMPL is definitely a very nice wx wrapping of MPL. My recollection
is that Ken McIvor wrote wxmpl after I showed him MPlot, but I'd defer
to Ken's version of the story. I'm also very happy that Ken's
maintaining the wx backend. I definitely spent most of the effort in
MPlot on bindings, printing, user configuration, and worrying about
being able to 'stripchart' (update a trace at close to 'real time').=20
I'm sure that some of what I wrote could be replaced with wxmpl or
matplotlib calls at this point. You may understand my reluctance to
do this (like it works and I have my own data to analyze and
applications to write), but I would not be opposed to seeing this
done.
I would also characterize wxMPL as being focused on the
programmer/script writer, not on the end user of an application. So
it's not exactly a 'wxPython Plot Widget'. But it might make the code
of MPlot easier to use/manage/improve.
On using matplotlib bindings and the Navigator toolbars, I'd guess you
don't want to do this. The toolbars are ugly, take up screen real
estate, do stuff you don't need and don't do stuff you do need. I'm
sure these are fine when you're doing a quick-n-dirty plot with an
'ipython -pylab' script, but I somehow never need to do that. Using
the matplotlib bindings would mean separate kinds of event handlers
for a MPL Panel and a non-MPL Panels. I guess that's inevitable, but
I'd still suggest sticking with straight wx.Bind methods. I don't
think the MPL bindings provide anything that can't easily be
reproduced, though it's been awhile since I looked at them.
Since you're short on time (we all are), I suggest giving MPlot a spin
and see if it does enough of what you need. I'd appreciate hearing
what does and doesn't. Finally, I was very happy to see your
response to the fairly silly 'use some other package', and agree
completely with your sentiment.
Cheers,
--Matt
PS: a very short wxPython / MPlot example:
import wx
import MPlot
import matplotlib.numerix as Num
x =3D Numpy.arange(0.0,10.0,0.1)
y =3D Numpy.sin(2*x)/(x+2)
app =3D wx.PySimpleApp()
pframe =3D MPlot.PlotFrame()
pframe.plot(x,y)
pframe.set_title('Test Plot')
pframe.set_xlabel(r'$R (\angstrom)$')
pframe.write_message('MPlot PlotFrame example: Try Help->Quick Reference')
pframe.Show()
pframe.Raise()
app.MainLoop()
Whoa! Thank you for all your answers. It's one of the most helpful mailing lists I ever joined. John: >There is some tutorial documentation, particularly Robert Leftwich's >tutorial - http://matplotlib.sourceforge.net/leftwich_tut.txt. This >link recently disappeared (by accident) from the FAQ entry >http://matplotlib.sf.net/faq.html#OO Thank you very much (and kudos for your work, by the way: the more I dive into it, the nicer it looks). I already had seen the faq entry, but the little tutorial by Leftwich with the class list just makes me feel better :) Ken: >An embedding library will give you those features, plus ones which >pylab does not (e.g. printing support, selecting points and regions). Ok. What I wanted to know is if in pylab there were hard-coded features that the MPL OO interface has not, or if these features were already present in MPL but simply had to be called and merged together by the user (don't know if I'm being clear here - anyway you seem to point it's the second, happier case). >It now checks to see if one already exists, so you can to use pylab >from your wxPython application without everything blowing up. Hmm. Evil temptation! But I'm more and more looking at wx embedding,anyway. Anyway it's nice to know it's an option if someone wants to hack something someday. Chris: >Be sure to join the wxpython-users mailing list. They (We) are every >bit as helpful as this group. I really hope so! Niklas: >First of all, why not take a look at an existing solution for AFM: >http://gwyddion.net/ >It looks very good and is already very mature. It provides a plugin >architecture, a modern graphical interface, is portable and seems to be >funded as well. However, it can only analyze surface data, and I don't >know if this is what you meant with '2d graph'. I didn't know about it. It seems really a good app, and I just mailed to my collegues if they know about it, it could help in our lab. Alas, (1) I'm all in that odd "force spectroscopy" thing (despite being two years I work with AFM, I never did an image!), and I don't see mention about it (2) I'd prefer to code my app to cover my needs. Who knows if it will be the app of someone else too? I hope to do a good enough work for it. I don't like that much to hack just for myself. Anyway if you know about good force spectroscopy analysis free software, let me know! Matt: >I would also characterize wxMPL as being focused on the >programmer/script writer, not on the end user of an application. So >it's not exactly a 'wxPython Plot Widget'. But it might make the code >of MPlot easier to use/manage/improve. I don't grasp what do you want to mean... if wxMPL is a wx interface for MPL, it seems focusing on the end user is the programmer's task, isn't it? and it seems right to me. In which sense is MPlot more "focused on the end user"? and what do you mean with "wxMPL is not exactly a 'wxpython plot widget'"? >On using matplotlib bindings and the Navigator toolbars, I'd guess you >don't want to do this. The toolbars are ugly, take up screen real >estate, do stuff you don't need and don't do stuff you do need. I agree toolbars are not essential, but they're nice IMHO. I don't strictly need them, except for the panning and zooming tools. Hope they're not hard to reproduce, should I have a look at the pylab code?). For the bindings, yes, I'd really like consistency between the graphic toolkit and MPL. >Finally, I was very happy to see your >response to the fairly silly 'use some other package', and agree >completely with your sentiment. Well, he just tried to be helpful. Anyway, after having heard both developers, I'm still confused about what to use, if wxMPL or MPlot... I think I'll give wxMPL a try, first. Thank you all for your long and informative answers. It's a bless to have both the MPL, wxMPL and MPlot developers being here to help me, along with such experienced and friendly users. It's two years I use almost exclusively free software, and nevertheless the both technical and human wonders of it don't cease to amaze me. Thank you all. Massimo -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
Massimo, > Matt: > >I would also characterize wxMPL as being focused on the > >programmer/script writer, not on the end user of an application. So > >it's not exactly a 'wxPython Plot Widget'. But it might make the code > >of MPlot easier to use/manage/improve. > > I don't grasp what do you want to mean... if wxMPL is a wx interface for > MPL, it seems focusing on the end user is the programmer's task, isn't > it? and it seems right to me. In which sense is MPlot more "focused on > the end user"? and what do you mean with "wxMPL is not exactly a > 'wxpython plot widget'"? Here's what I think the fundamental differences are. Maybe Ken can give an opinion too. wxMPL gives a nice and relatively complete set of tools with which you can build any MPL functionality into a wxPython application. You'll have to do some MPL-aware programming with wxMPL to get it to do what you want. Like (correct me if I'm wrong, Ken), you'll have to explicitly enable/disable zooming, and add your own GUI controls for having user-set titles and such, and know that to plot, you need to get the axes from the figure and use axes.plot(). I believe there is no user-level way for altering the plots made with wxMPL. In contrast, MPlot provides a PlotPanel and PlotFrame that already have bindings for zooming, picking coordinates, and so on built in, has a plot() method of its own, and also provides a GUI form (from a pop-up menu that shows up on right-click) for users to change plot titles, placement of legend, font sizes, and symbol and line types and colors for the different 2D traces. To do this, MPlot does make forced choices for bindings -- zooming is by dragging a rubberband box, coordinates show up only on left-click, etc (I believe that wxMPL also makes similar forced choices. This greatly reduces the need for mpl-aware coding. You simply say self.plotframe =3D MPlot.PlotFrame(self) self.plotframe.Show() self.plotframe.plot(xdata,ydata) you don't need to worry about bindings or making a form for the user to change the plot titles or colors or use the matplotlib OO API at all. MPlot takes care of that, or tries to anyway. > if wxMPL is a wx interface for MPL, it seems focusing on the end user is = the programmer's > task, isn't it? and it seems right to me With wxMPL it is, and wxMPL gives tools to programmer to make applications. With MPlot, much of what you'd want is already built in: it is a plotting component ready to be put into an application.=20 You could write your own wxHTML widget yourself too, or you could use the one that already exists. It's simply a question of using pre-existing packaged solutions or rolling your own from lower-level parts. > In which sense is MPlot more "focused on the end user"? MPlot provides user-level control of plot characteristics (line type, color, symbol type, titles) with a GUI form and a reasonably complete set of functionality (printing, saving, etc). Just creating a MPlot PlotPanel provides all that functionality. > and what do you mean with "wxMPL is not exactly a 'wxpython plot widget'"= ? Well, I'd say it's a class library from which one can build wxPython plotting widgets. Personally, I want a wxPython plotting widget that is a little further removed from the underlying plotting library but is also pretty feature heavy. I don't want to have to use the low-level matplotlib API to say in a wxPython Program: 'make a wxPlotter', and 'plot x,y to the wxPlotter'. I looked closely at wxPyPlot when I wrote MPlot (and I had a similar wrapping of BLT that I've used -- really, a consistent interface is highly useful and easy on users). I wanted something at a high enough level that knowledge of matplotlib is not necessary for an enduser to use a PlotPanel, or even for a wxPython programmer to use it in a program. In my opinion, MPlot ends up looking a lot better than wxPyPlot -- all because of matplotlib. Hope that helps, and that Ken (or anyone else) can clear up anything I've got wrong. --Matt
On 12/01/05 16:13, Matt Newville wrote:
> Here's what I think the fundamental differences are. Maybe Ken can
> give an opinion too.
My take on things is that WxMpl and MPlot solve two different problems. WxMpl
is intended to be a FigureCanvasWxAgg that has some pointy-clicky user
interactions (e.g. zoom) built in. I gather that Matt considers it "focused
on the programmer/script writer, not on the end user of an application"
because it doesn't provide end-users with any means to edit the plot. MPlot
lets users interactively change the title, axes labels, etc.
I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his approach
wasn't solving my problem: I was thrilled what matplotlib and wanted *all* of
it to Just Work with wxPython. Allowing users to edit plots was less important
to me than supporting as many kinds of plots as possible. By focusing on
adding user interaction to FigureCanvasWxAgg I was able to support all of
matplotlib's OO API in one fell swoop.
> Like (correct me if I'm wrong, Ken), you'll have to explicitly
> enable/disable zooming, and add your own GUI controls for having user-set
> titles and such, and know that to plot, you need to get the axes from the
> figure and use axes.plot(). I believe there is no user-level way for
> altering the plots made with wxMPL.
Zooming and point-under-cursor are enabled by default. You are correct, WxMpl
provides no GUI tools to allow application users to alter plots.
> To do this, MPlot does make forced choices for bindings -- zooming is by
> dragging a rubberband box, coordinates show up only on left-click, etc (I
> believe that wxMPL also makes similar forced choices.
Yep. I've followed the BLT convention of zooming by selection a rectangular
area and unzooming by right-clicking.
>>if wxMPL is a wx interface for MPL, it seems focusing on the end user is the programmer's
>>task, isn't it? and it seems right to me
>
> With wxMPL it is, and wxMPL gives tools to programmer to make
> applications. With MPlot, much of what you'd want is already built
> in: it is a plotting component ready to be put into an application.
> You could write your own wxHTML widget yourself too, or you could use
> the one that already exists. It's simply a question of using
> pre-existing packaged solutions or rolling your own from lower-level
> parts.
As always, there is a trade off involved. In other words, MPlot would be a
sensible choice if allowing users to edit their plots is very important.
WxMpl makes sense if having access to all of MPL's plotting abilities is very
important. Furthermore, there's nothing stopping someone from adding support
for more kinds of plots to MPlot or from building a plot editor on top of
WxMpl, if they were so inclined.
>>and what do you mean with "wxMPL is not exactly a 'wxpython plot widget'"?
>
> Well, I'd say it's a class library from which one can build wxPython
> plotting widgets.
Well I'd say it's a wxPython plotting widget that lets you build plot editors.
I guess it all depends on your definition of "wxPython plotting widget". :-)
> I don't want to have to use the low-level matplotlib API to say in a
> wxPython Program: 'make a wxPlotter', and 'plot x,y to the wxPlotter'.
As I said earlier, I think we're trying to solve different problems. I do want
to use the low-level matplotlib API, because it's a more flexible and
powerful. If necessary, I want to be able to say in a wxPython program "make
a wxPlotter and then make two subplots, one a line plot with two embedded
axes, the other a histogram and a line plot, and then chain their X axes
together".
> I wanted something at a high enough level that knowledge of matplotlib is
> not necessary for an enduser to use a PlotPanel, or even for a wxPython
> programmer to use it in a program.
I hadn't considered "end users" when writing WxMpl, on the notion that they
weren't going to be writing their own wxPython applications any time soon.
That being said, I have added some convenience classes to make WxMpl easier to
use for ad hoc plotting.
> In my opinion, MPlot ends up looking a lot better than wxPyPlot -- all
> because of matplotlib.
Matplotlib is an incredible piece of software. I agree with you, John
deserves to be knighted.
Ken
P.S. Since Matt posted a short MPlot example, I figured I should post a short
WxMpl counter-example :-P
import wxmpl
import matplotlib.cm as cm
import matplotlib.mlab as mlab
import matplotlib.numerix as nx
dx, dy = 0.025, 0.025
x = nx.arange(-3.0, 3.0, dx)
y = nx.arange(-3.0, 3.0, dy)
X,Y = mlab.meshgrid(x, y)
Z = (1- X + X**5 + Y**3)*nx.exp(-X**2-Y**2)
class MyPlotApp(wxmpl.PlotApp):
ABOUT_TITLE = 'WxMpl Example'
ABOUT_MESSAGE='Behold! An example!\nCopyright 2005 Yoyodyne Inc'
app = MyPlotApp(title='WxMpl Example')
figure = app.get_figure()
axes = figure.gca()
img = axes.imshow(Z, cmap=cm.jet, extent=(-3, 3, -3, 3))
figure.colorbar(img)
axes.set_title('$(1 - X + X^5 + Y^3)*e^{\/^{(-X^2-Y^2)}}$')
axes.set_xlabel('X Axis')
axes.set_ylabel('Y Axis')
app.MainLoop()
Hey, I didn't want to start a flamewar on all this! Please breath! :) >>My take on things is that WxMpl and MPlot solve two different problems. Here's how I do see things now, based on your descriptions: - pylab is made for pure interaction or quick-and-dirty (but nevertheless useful) scripts for interactive data analysis - MPlot is thought "in between", for advanced scripting or simple programming: it allows the end user to do quite complex things with not so much programming and other users of the script to interact with the plot, giving up some strict programming flexibility. - wxMpl is thought for programming: it requires knowledge of WxWidgets, a bit more abstraction and careful thinking from the programmer, but it gives maximum flexibility. Note that I said "is thought", not "is made only for": it is surely possible to script with wxMpl and to do advanced programming with MPlot. I just want to understand the objectives of the three projects. It is true in your opinion? > Well, that and the fact that to use wxMPL you have to understand > matplotlib. Like, that > a figure has an axes, and axes has 'plot()' and 'imshow()'. Well, I see nothing really bad in it. To fully use the power of a library, I guess you should understand how does the library works, or at least what its APIs are. >>I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his approach >>wasn't solving my problem: I was thrilled what matplotlib and wanted *all* of >>it to Just Work with wxPython. > I think it would be much better for everyone if we could work on a > single solution and I was pretty disappointed when I showed you what I > had and you went off and wrote something else that fills very many > similar niches. I'm sure MPlot is not as fancy or subclassed as > wxMPL, but having a common wxPython plot control based on matplotlib > that was easy to use and just ready to plug into an application would > be better for everyone, I think. >[...] > I understand that for _you_ a library that wx-dresses > matplotlib is OK, but why not try to have a good feature-rich plotting > package for wxPython? I have only tried a little wxmpl, and still didn't try MPlot, but I was wondering: can MPlot be rewritten using WxMpl? In this way we wouldn't have to "choose" and to fork the goal of a unified wxPython/MPL solution. Instead, we would have a flexible stack of solutions at different levels. WxMpl would stay less or more as it is, providing a quite low level interface for people who need/like it (I feel I'm among these people, although it's still very possible to change my mind). On top of it, MPlot would extend WxMpl, creating advanced wrappers and controls to ease things for who needs "intermediate" scripting (a need that I think is very real). And possibly in future Pylab would stay on top of this stack, using MPlot and WxMpl to deal with interactive plotting. >>Allowing users to edit plots was less important to me than supporting as many kinds of >>plots as possible. > > Really? I find this hugely important. For mapping, it will be vital > to allow the user to adjust contrast and change color maps, where > user-driven changing of data value -> display is critical for > understanding the data. Well, it depends on the data you're using and on what you're doing. For the work I'm planning, I don't need all of this: I'd prefer integration into an application and full MPL support. But it's true that there are situation in which you badly need something like that. I think the "stack" solution can be an idea. > Yes, provided you know matplotlib. Which is, to be fair, kind of > quirky. I mean is all of > app = MyPlotApp() > figure = app.get_figure() > axes = figure.gca() > axes.plot(x,y) > > really necessary? I've seen the matplotlib code, and have used a > fair number of plotting libraries in my day. The matplotlib results > are wonderful, but the API is a bit goofy, don't you think? Does > FigureCanvas->Figure->Axes make sense to you? I'd be OK with two of > those, but I don't understand how three possibly helps. I think having the 'privilege' to deal with object properties is good in the end for the programmer, although it can be confusing for the noob. > I'm also really very concerned about the priority given to pylab and ipython. I'm really concerned about it too. As a MPL newbie, I found it very misleading. I'd like to see a full programming stack on top of MPL, with pylab, MPlot and wxMpl being integrated components of it, and with a nice documentation about it. >>As I said earlier, I think we're trying to solve different problems. I do want >>to use the low-level matplotlib API, because it's a more flexible and >>powerful. If necessary, I want to be able to say in a wxPython program "make >>a wxPlotter and then make two subplots, one a line plot with two embedded >>axes, the other a histogram and a line plot, and then chain their X axes >>together". > > How often do you actually do this? Does it need a library? I'd > guess 80% of the results could be had with a much higher-level > interface. A grid of multiple plots is certainly possible by packing > panels together. I don't use histograms or bar graphs much myself, > but these would be trivial to add to something with a more MPlot- (or > if you like, more BLT-)like interface. You have different needs. I feel next to the needs of Ken, but for example my desktop neighbour here that does AFM imaging would feel on the side of Matt. It is useless to say "how often do you do this?", because you don't know what my needs are. I think a scientific library should be as much general and agnostic as possible. > I think you may be in the mindset of a library-writer where 'user' is > an application developer. The question was about writing applications, > and there User is the person running the program. They care 0% about > the cleanliness of the API, but if the fonts too small or they change > the red solid line to blue dots, the program sucks. I think the user wants to see a good program. I think the programmer (that sometimes is the user, sometimes is not) has the responsibility to care about usability details, not the user. So if the fonts are too small, it's a problem that the programmer must solve. I'm all for configuration (I hate people that say "configurability confuses users") but it can be embedded in, let's say, a .myplotrc. But that's my opinion, and I understand you want more direct user interaction, instead. I understand you felt disappointed when you did MPlot and your friend (I hope you're friends) went away and did something else. I think simply you should try to collaborate to fit both niches in a coherent stack, instead of competing for the wx and MPL union. Massimo -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
massimo sandal wrote: >>I'm also really very concerned about the priority given to pylab and ipython. > > > I'm really concerned about it too. As a MPL newbie, I found it very > misleading. I'd like to see a full programming stack on top of MPL, with > pylab, MPlot and wxMpl being integrated components of it, and with a > nice documentation about it. Chill out, there is no dark plan here :) It's simply a matter of usage patterns: my personal audience is one of other programmers, I'm mostly an algorithms developer and the code I write is used by other mathematicians, physicists, etc. to write programs. Hence, command-line, interactive use is _my_ priority, and I did the work (along with John's and others' help) to make sure that mpl would work as well as possible in this context. I have currently no need to write GUIs, so I haven't worked on that. Others also liked these capabilities, and contributed for example the interactive Qt support. I think it's great that a nice set of OO, high-level tools is being developed for MPL with WX, I may even need those in the future. If others need similar Qt or Tk-based tools they may also develop them, which is great as well. You need to understand that this is simply how free software works: when someone needs something badly enough _for themselves_, they get off their butt and write it. Then it's available for all to use (if released). I did that for interactive mpl support over a year ago, so that's why it's been prominently displayed for a while (and this _is_ useful to a lot of people, since quick-and-dirty interactive data analysis is a very common task). Now you guys are doing the same for WX tools, and that's fantastic. I'm sure John will advertise it equally prominently. So relax, nobody is trying to be misleading about anything, we're all here simply working on what each of us needs, so the evolution process is rather inhomogeneous. Cheers, f
>>>>> "Ken" == Ken McIvor <mc...@ii...> writes: Ken> Matplotlib is an incredible piece of software. I agree with Ken> you, John deserves to be knighted. Just let me know when and where to show up :-) Ken> P.S. Since Matt posted a short MPlot example, I figured I Ken> should post a short WxMpl counter-example :-P Ken, Matt: would either or both of you like to bundle these packages into the mpl releases so they would be easier for users to find and use? We could either put them in the main release or in a "toolbox". JDH
> Ken, Matt: would either or both of you like to bundle these packages > into the mpl releases so they would be easier for users to find and > use? We could either put them in the main release or in a "toolbox". As a (new) MPL user, I think it's an excellent proposal. Both WxMpl and MPlot are MPL extensions, anyway, and they're probably extremly useful for a large proportion of MPL users. I'd like to know what do you all think about the wxmpl < mplot < pylab stack idea, by the way... m. -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: mas...@un... tel: +39-051-2094388 fax: +39-051-2094387
On 12/01/05 04:43, massimo sandal wrote: > Ken: > >An embedding library will give you those features, plus ones which > >pylab does not (e.g. printing support, selecting points and regions). > > Ok. What I wanted to know is if in pylab there were hard-coded features > that the MPL OO interface has not, or if these features were already > present in MPL but simply had to be called and merged together by the > user (don't know if I'm being clear here - anyway you seem to point it's > the second, happier case). I think I understand the question now. I thought you were worried about interactive plotting features, but I now believe you're asking about plotting in general (please correct me if I'm wrong!). In terms of plotting, etc, I can't think of anything that pylab can do that you can't do using the OO API. You sometimes have to do a bit more work (because pylab manages a lot of details for you), but I haven't ran into any major problems. Of course, I'm using about one tenth of matplotlib's capabilities in my day-to-day work (plot(), imshow(), pcolor()), so you're milage may vary slightly. :-) > >On using matplotlib bindings and the Navigator toolbars, I'd guess you > >don't want to do this. The toolbars are ugly, take up screen real > >estate, do stuff you don't need and don't do stuff you do need. > > I agree toolbars are not essential, but they're nice IMHO. I don't > strictly need them, except for the panning and zooming tools. Hope > they're not hard to reproduce, should I have a look at the pylab code?). Here are the toolbar classes: WX backend -- matplotlib.backends.backend_wx.NavigationToolbar2Wx WXAgg backend -- matplotlib.backends.backend_wxagg.NavigationToolbar2WxAgg NavigationToolbar2WxAgg just overrides the "get_canvas(fig, frame)" method to return a FigureCanavsWXAgg, so you'll want to look at NavigationToolbar2Wx if you're interested in how it works. The following files in the "examples/" subdirectory of the source distribution make use of a WX toolbar. They should help you get started, if you choose to go that route. dynamic_demo_wx.py dynamic_image_wxagg2.py embedding_in_wx2.py embedding_in_wx4.py wxcursor_demo.py Ken
On 12/02/05 04:54, massimo sandal wrote: > Hey, I didn't want to start a flamewar on all this! It's not a flamewar! Matt and haven't began maligning each other's ancestry yet! :-) > I just want to understand the objectives of the three projects. > It is true in your opinion? I'd say you've got it right. >> I understand that for _you_ a library that wx-dresses >> matplotlib is OK, but why not try to have a good feature-rich plotting >> package for wxPython? > > I have only tried a little wxmpl, and still didn't try MPlot, but I was > wondering: can MPlot be rewritten using WxMpl? It certainly could. WxMpl could take care of the basic user interaction stuff (e.g. zooming), leaving MPlot to focus on plot editing features. > But it's true that there are situation in which you badly need something > like that. I think the "stack" solution can be an idea. I really like the idea of stacking the different levels of abstraction on top of each other. It would allow us to reduce code duplication without limiting what application developers can do with matplotlib. >> I'm also really very concerned about the priority given to pylab and >> ipython. > > I'm really concerned about it too. As a MPL newbie, I found it very > misleading. I haven't really given it much thought. Most people presumably use MPL from IPython or scripts via pylab, so focusing documentation efforts on it make sense. I think that getting a good OO API manual would really improve things for application developers, but might be hard to justify in the big-picture. Ken
John, I would be inclined to vote for the toolbox option. I gather that these are substantial backend-specific extensions, so they don't seem very appropriate for the main mpl package. Disclosure: I don't use wxpython and haven't tried it recently. Eric > Ken, Matt: would either or both of you like to bundle these packages > into the mpl releases so they would be easier for users to find and > use? We could either put them in the main release or in a "toolbox". > > JDH
Ken McIvor wrote: > I haven't really given it much thought. Most people presumably use MPL > from IPython or scripts via pylab, so focusing documentation efforts on > it make sense. Not really. Most people use pylab, because that's what's well documented, not the other way around. Also, a lot of us have matlab experience, so pylab is easier that way. That being said, I don't like it much, I'd much rather have a nice, pythonic interface. I don't see any reason that a good OO API couldn't be just as effective for quick scripting as the current pylab one. I'd be happy not to have to keep track of which is the current axis, and keep having to call gca() and friends. > I think that getting a good OO API manual would really > improve things for application developers, but might be hard to justify > in the big-picture. I think application developers are a big part of the big picture, in fact. I had the idea of writing a version of the MPL manual using all OO syntax. I'd still like to do that. It would provide a useful document, and be a good test bed for what features really are miss or are more awkward to do with an OO style. Maybe one of these days I'll actually work on it! Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Chris, Christopher Barker wrote: > Ken McIvor wrote: > >> I haven't really given it much thought. Most people presumably use >> MPL from IPython or scripts via pylab, so focusing documentation >> efforts on it make sense. > > > Not really. Most people use pylab, because that's what's well > documented, not the other way around. Also, a lot of us have matlab > experience, so pylab is easier that way. Don't understimate the importance of this group of users, present and potential. For a lot of people doing a lot of things, the Matlab/pylab approach works very well. Sometimes OO programming is a good way to go, but it is not the best approach in all cases. One of the strengths of python itself is that it works fine with or without OO style; mpl brings that strength to 2D graphics. Eric