Hey, I didn't want to start a flamewar on all this!
>>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()
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
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.
University of Bologna
Department of Biochemistry "G.Moruzzi"
Via Irnerio 48, 40126 Bologna, Italy