From: Matt N. <new...@ca...> - 2005-12-01 22:13:47
|
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 |