Re: [Matplotlib-users] advice on writing an application

[Matt N. <new...@ca...>]

HI,

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).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 customization=
s.

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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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 le=
vel
> interface, at least hypothetically.  Things like creating two subplots th=
at
> share an X axis (so they zoom together) would be a bit hairy, but I'm sur=
e 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 rewri=
te
> the user interaction code to add support new things, like subplots and
> overlapping Axes.  Providing this kind of support initially was an import=
ant
> 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 poss=
ibly
> > helps.
>
> I don't think it's goofy at all.  You have FigureCanvas because seperatin=
g 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 tha=
t'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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fernando said:

> > >I'm also really very concerned about the priority given to pylab and i=
python.
> >
> > 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, wit=
h
> > 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.=20
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