I agree with Ken -- this is definitely not a flamewar. I have no
ill-will toward anyone here, or any of the codes in discussion. In
fact, quite the opposite. I also do not have a lot of time to devote
to this discussion or MPlot itself, mostly due to running experiments
and working on and supporting about other analysis software. I have
very little allegiance to MPlot, take no pride in it and in no way
'want it to win' over anything else. I do want something that has the
end-user level flexibility of MPlot, and would happily use something
else if available. I am committed to wxPython because, while a
long-time and confirmed Unix (now linux/OSX) person, about 90% of the
'scientific customers' for my software use Windows (and at my age and
baseline crankiness, I don't convert easily to anything).
···
==================
Massimo wrote:
I have only tried a little wxmpl, and still didn't try MPlot, but I was
wondering: can MPlot be rewritten using WxMpl?
Definitely. Volunteers welcome. My only advice here would be to
remember that bridging wxPython and matplotlib should use the best of
both and that the maintainers will have to know both, but the users of
the library should probably not have to know anything about
matplotlib, because they're going to be asking "I'm writing this wx
Application and want to include a graph -- what should I use?".
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.
I agree.
==================
John wrote:
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".
This is OK with me, but I can go either way. I sent MPlot to you over
a year ago and suggested that it could be included with MPL. At the
time, I think you had no 'toolbox' model for that kind of thing.
==================
Andrew wrote:
My idea is for an interaction model similar to most spreadsheet graph
objects (e.g. Excel), where context menus control the individual
components of the plot(s). Perhaps with introspection, many of the
customizable features could be automatically extracted and presented to
the user, so that menus and dialog boxes wouldn't have to be completely
coded by hand.
I'd like the plot to appear simple (by default), but with suitable
access (perhaps triggered by mouseover?) to hidden features like a
toolbar, scrollable axes, crosshair cursors (with coordinate readout),
and zoom controls.
I'm certainly willing and able to contribute to this development. I'm
conflicted as to which code base to begin with, however.
There's potentially a lot of flexibility and actions to trigger there.
With BLT (and Pmw.BLT) clicking on a component (say, a trace or label)
could cause a 'configure' box to modify its attributes (line color,
etc). I found this could confuse users who would accidentally click
on things, but it's not a terrible model. For MPlot, I made
Menu->Option->Configure or
right-click->pop-up->Configure bring up a form for many graph customizations.
To do this kind of interactivity, I believe that mpl would have to
support it, and that might be tricky using the wxAgg backend (that
is, I'm not sure how easy it would be to convert coordinates on the
agg-image back to the Artist that rendered it). So I think clickable
plot objects is a reasonable way to go, but I might not make it the
highest priority.
==================
Ken wrote:
> So, out of curiousity which of the *all* the features do you actually
> use that can't be wrapped away to a higher level interface?
I can't think of any features that can't be wrapped away into a higher level
interface, at least hypothetically. Things like creating two subplots that
share an X axis (so they zoom together) would be a bit hairy, but I'm sure it
could be done.
Oh, well I think this would get so application specific that it would
be just as easy to do it at the GUI level than at the MPL level.
That being said, it would be frustrating if you had to periodically rewrite
the user interaction code to add support new things, like subplots and
overlapping Axes. Providing this kind of support initially was an important
goal while writing WxMpl.
Oh the 'user-level support code' is definitely the larger part of the
work for adding any plot type. With imshow(), you'd need to provide a
GUI to choose color tables and scalebars to adjust levels and
contrast, and have a place on the GUI for displaying coordinates and
intensities. And of course, zooming, flipping, etc. For the
application we both happen to most need false-color-maps for (x-ray
fluorescence), I'd also want a way to put overlay one map in red and
another in green (with user-selectable colors of course). So adding
'axes.imshow()' is the easy part. Thanks to matplotlib. I did this
once with PIL and the Tk canvas -- and I'm using that program today,
as it turns out.
> 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 don't think it's goofy at all. You have FigureCanvas because seperating out
the thing that "draws" the figure is the best way to implement backend
neutrality. You have Figure and Axes (rather than just Axes) because that's
the best way to implement things like subplots, plotting overlapped axes, and
figimage(), colorbars, and figure legends.
I think we agree: the hierarchy is implementation driven, not use driven.
> A grid of multiple plots is certainly possible by packing
> panels together.
That's not quite what I meant:
http://matplotlib.sourceforge.net/examples/shared_axis_demo.py
All I'm saying is that this _could_ be handled at a GUI level. The
advantage there is that you absolutely know someone using a wxPython
plotting widget will know wxPython, whereas their understanding of
matplotlib may be zero.
==================
Fernando said:
> >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.
I think Fernando is not quite understanding the concern or complaint.
I also don't think anyone is 'hot' about it either. And I know that
Ken and I both "understand how free software works". As it turns out,
I'm mostly 'an algorithm developer' too and write open source
applications that other scientists use as well.
Certainly IPython is very nice, and has an important niche -- I've
even used it a couple of times myself. The issue (for mpl) is that it
may appear to be the "normal" way one uses mpl. I do find that to
similar to confusing python with IPython. IPython is one way to use
python, but it's not only way .... and it's not driving decisions
about python.
For mpl, I believe that the 'make a wx mainloop for a command-line
program' did drive some fairly ugly business in backend_wx.py that
ended up making it harder to use backend_wx for GUIs. I tried to
patch this to be favor GUI writers, but the conflict was resolved in
favor of the wx-mainloop-in-commandline. I believe this may be fixed
now.
More importantly, when discussing matplotlib the usage is generally
given in terms of pylab, and often 'from pylab import *', which
conveys the idea that matplotlib is intended for writing quick-n-dirty
code. And, as you can see from this discussion, the best way to use
it in real GUI applications is not always well resolved <wink>. So
it is easy to conclude that pylab and ipython -pylab are given
priority.
I stand by my concern about this, and I think you're missing an
important point if you easily dismiss the fact that Massimo's found
this to be misleading.
Finally, I'll be out of town and won't be able to respond for at least
a week. Sorry this was so long, and thanks again.
-Matt