matplotlib-users Mailing List for matplotlib

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

Ken,
>>>That being said, it would be frustrating if you had to periodically rewr=
ite
>>>the user interaction code to add support new things, like subplots and
>>>overlapping Axes. Providing this kind of support initially was an impor=
tant
>>>goal while writing WxMpl.
>>
>> Oh the 'user-level support code' is definitely the larger part of the
>> work for adding any plot type.
>
>I should have been more specific and said "plot-level user interaction cod=
e,
>like zooming". For example, adding support for subplots means you need to=
 add
>support for picking out which Axes object the user has drawn the selection
>over and rejecting the selection if it overlaps multiple Axes.
I think that's just the tip of the iceberg. If you have multiple
'Axes' -- I'd call them multiple graphs --- in an application, the
application writer may very well want to let the user decide which
plot goes to which graph. How would this be handled? Well, at the
wxMPL/MPlot layer --- which means it does not have to be at the mpl
layer.
If multiple graphs were handled as each one being an instance of a
Plotting Panel, that would probably seem quite natural to a wxPython
author. They could be layed out anyway you'd like (they wouldn't
have to be contiguous or even on the same frame) and the wxPython
author could handle wehre 'the blue trace in graph 1' was the same as
'the green trace in graph 2' or scales of two graphs were somehow
related.
When you take the view of a Toolkit-aware programmer trying to add
graphics to their application, the details of the mpl implementation
seem less important and a few of its more whizbang features seem
pointless,
For multi-valued maps as with x-ray fluorescence (that is, a map that
is L x N x M for L
elements and N x M spatial pixels with L ~=3D 10, N ~=3D M ~=3D 100) whic=
h
I look at all the time, I very much want a LxL grid (or pick a subset
of the L elements and have an L' x L' grid) of graphs that W.S.
Cleveland (in 'The Elements of Graphing Data') called "ScatterPlots"
(that term has a different connotation now): At each cell along the
diagonals of the grid is a NxM false color map for an element's
intensity, the off-diagonal cells have the correlation plots for each
i,j pair of elements. The user can highlight any patch on any
sub-graph and the data points falling in that region are highlighted
on all the other graphs. So one can pick out the all the points with
highest As levels, and see immediately what the Fe and Zn levels are
at those points.
I humbly submit that this would be best handled at the GUI level.
--Matt

On 12/02/05 14:11, Matt Newville wrote:
> Ken wrote:
>>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's possible, but there is already a quick and well-documented way to do it 
at the MPL level. Situations like that, where there's already a 
backend-portable way to do things, are what WxMpl tries to cater.
>>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.
I should have been more specific and said "plot-level user interaction code, 
like zooming". For example, adding support for subplots means you need to add 
support for picking out which Axes object the user has drawn the selection 
over and rejecting the selection if it overlaps multiple Axes.
Ken

> From: Ken McIvor [mailto:mc...@ii...]=20
> To: Henshaw, Andy
>=20
... snipped
>=20
> It sounds you'd like to see a library with a simplified API=20
> that supports most kinds of plots while letting users edit=20
> things like the axes title, line width, number of histogram=20
> bins, etc. Am I correct?
Exactly right.
... snipped
>=20
> I would definitely go with introspection and declarative=20
> programming. First, come up with a reasonable object picking=20
> algorithm (see the `object_picker.py'=20
> example). Let matplot manage all of the plot objects' data=20
> (axes title, line style, edge color, etc). Use declarative=20
> programming to define the editable parameters for each=20
> object. Finally, use introspection to map between type of=20
> the object and the list of editable parameters. PEP 246=20
> adaption might be useful here, since it would let you break=20
> the tight coupling between types and their parameters:
Thanks! I'll look at that. =20
... Code snipped
> It might be a good idea to bug John about matplotlib=20
> transitioning to using the Traits package from Enthough,=20
> which would take care of managing the object parameters for=20
> you. They developed it for use in their Chaco plotting=20
> library, which went MIA shortly after release.
>=20
> > I'd like the plot to appear simple (by default), but with suitable=20
> > access (perhaps triggered by mouseover?) to hidden features like a=20
> > toolbar, scrollable axes, crosshair cursors (with=20
> coordinate readout),=20
> > and zoom controls.
>=20
> A toolbar that pops up via mouseover would be pretty=20
> impressive, but I can't think of a way to implement it off=20
> the top of my head. I'm not sure what you mean by=20
> "scrollable axes". Do you mean pannning, the way pylab plots work?=20
In most cases, yes. Although, sometimes, I'd rather have a scrollbar
associated with an axis, particularly when I have data that is recorded
versus time. The scrollbar provides a context for how much of the data
set is currently visible and thumbtracking provides a fast way to scan
through it. But, I can live without that. I can imagine that it would
be clumsy to provide, in the general case.
> Crosshair cursors are easy and coordinate readout are pretty=20
> easy and I believe they already work in both MPlot and WxMpl.=20
> Likewise zoom controls.
Right, I'd just like to hide it all when the user isn't interacting with
the panel.
>=20
> > I'm certainly willing and able to contribute to this=20
> development. I'm=20
> > conflicted as to which code base to begin with, however.
>=20
> I'm not sure what to recommend. Merging MPlot and WxMpl so=20
> that MPlot uses WxMpl for rendering and plot-level user=20
> interactions like zooming would be one way to start. I think=20
> you'd probably be better off going with a more dynamic=20
> approach to parameter editing, since it would be a bit more=20
> work up front but a lot less work to add plot types. If done=20
> right, the object picking and parameters stuff could even be=20
> backend independent.
>=20
Yes, I'd really like to get away from building static dialog boxes.
Ideally, we wouldn't have to touch this layer, even when MPL added
features. =20
Having the "object picking and parameter stuff" be backend independent
was not in my original thoughts, but, if it is doable, I can see that it
would be the best approach.

Matt Newville wrote:
> 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.
OK, I don't have the time to get into a long-winded discussion here. My 
simple point is that the reasons for the ipython/pylab presence in the public 
docs are mostly historical: over one year ago, I needed this, I wrote it and 
it got integrated (both mpl and ipython needed changes for this to work). I 
should even add that I use Tk, not WX/GTK/Qt at all, so I could have lived 
without this support, but I figured that it would be a good thing to have a 
well-rounded interactive support.
Now, those using mpl as a library for handling plotting in GUI apps are 
becoming a growing group: I think that's GREAT! I will probably benefit 
myself from these developments in the future, as I may need WX support for 
other things.
I am not _dismissing_ anything. I am simply saying that if this is a need of 
a group of users, then the mechanisms exist to address it. But saying that 
the docs 'have' to present one aspect vs another is, in a free software world, 
misplaced. No free software project 'has' to do anything: it does what those 
writing the code make it do, end of story.
When 'pitching' mpl to other users, I always stress how the fact that it's a 
_library_ (instead of a program like gnuplot) is one of its greatest 
architectural assets. While I personally don't use it as such (I could still 
get by with gnuplot and would be fine, given my needs), I use mpl because I 
like to know that, were I to need a more complex usage mode, the library 
allows me to do so. So I am fully aware of the value and importance of this 
aspect of mpl.
To summarize: there's a need for easy, interactive plotting in python. 
ipython/pylab address that reasonably well. There's also a need for easier 
usage of mpl in a more complex WX context: you guys are working on improving 
the situation here, and that's an excellent development.
The only sense in which the first aspect was given 'priority' was historical: 
we wrote that code over a year ago. As your solutions mature and become 
publicly documented, I'm sure they will be given equal space, since they 
address a _different_ problem than pylab/ipython do. Not more important, not 
less important: different.
I'm afraid that this is drifting off-topic, so I'll probably close it here. 
It seems I wasn't very successful in clarifying a simple fact of the evolution 
of matplotlib I was involved with, without generating more noise than 
necessary. Sorry about that.
Cheers,
f

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

massimo sandal wrote:
>> 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.
> 
> 
> Perhaps I hadn't been clear. I'm not complaining of features missing. I'm
> just saying that, for example, the docs are misleading, because they focus
> on pylab when they would have to show both pylab and the OO interface.
The docs don't "have" to show anything: they are as complete as the people who 
wrote them have had the time/energy/interest/ability to make them.
It may well be true that the OO interface is under-documented (I don't know). 
If that is the case, then a worthwhile contribution woudl be to write such 
documentation, or to organize the existing one better. The mpl wiki cookbook 
is there for all to contribute, so you don't even need to bottleneck on John's 
time or resources. A good set of OO pages/tutorials on the wiki, with examples 
and summaries of WXMPL/MPlot/whatever would (if it doesn't exist already) be 
an excellent contribution that users can make.
John has already explicitly said that he'd like to see wxmpl/mplot included, 
so he's obviously open to contributions on this front.
Cheers,
f

On 12/1/05, Charlie Moad <cw...@gm...> wrote:
> It would help if you were more specific. Are you referring to
> animation or static images? I can generate a million point scatter
> plot in under a minute, and I would consider this pretty good for a
> general purpose plotting package.
Hi matplotlib'ers!
while the end result in matplotlib is starting to "get there", the speed is
not yet where it has to be to be useful IMO. I hereby post a little challen=
ge
for the matplotlib developers;
get the actual plotting time (from the first plot command until show is don=
e)
on the below dataset down to less than a second,(including the quiver
command in the plot.py file).
download the 3 files here (ca 600kb in total)
http://www.ii.uib.no/~avle/slow1/
execfile('plot.py') to plot the dataset (works for me with cvs as of today)=
.
 the first part of the file is just some convenience funcs for loading
the data. the plotting happen near the end.
this is a moderately sized grid, 433x560 cells (those of you into
oceanography may recognize the area). what I observe on my pentium
2.54ghz linux box:
-after "data ok" on screen, it takes ca15s to render. pygist uses < 0.5s
-zoom operations take ca 5s. pygist is "instant".
-you don't want to wait for an additional quiver layer. it must take
minutes to finish. pygist is instant. with quiver, also zooming is
equally slow, the ui freeze for ages.
-often one wants to add contours from other fields on top of this, in
pygist this adds no
 visible delay, matplotlib easily doubles the rendering time.
typical usage for me is to load many such datasets, and do a lot of
zoom in/out/pan to various features, modify colors/levels, add
velocity vectors etc. currently this is quite
painful in matplotlib, as one zoom operation on realistic datasets
easily takes 10 seconds on a multi ghz machine. pygist is very fast,
even on a 400mhz laptop, memory usage is also a lot lower.
so, I think matplotlib is a great effort, and shows a lot of promise, but
for realistic use, it is (at least for me) still far too slow!
Helge

On 12/02/05 09:26, And...@gt... wrote:
> I'd like to have many more features available to the user than are
> currently provided by Mplot, but when I'm coding I'd like to be able to
> drop in a complete panel without having to do the coding that I'd need to
> do with WxMPL.
It sounds you'd like to see a library with a simplified API that supports most 
kinds of plots while letting users edit things like the axes title, line 
width, number of histogram bins, etc. Am I correct?
> 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 would definitely go with introspection and declarative programming. First, 
come up with a reasonable object picking algorithm (see the `object_picker.py' 
example). Let matplot manage all of the plot objects' data (axes title, line 
style, edge color, etc). Use declarative programming to define the editable 
parameters for each object. Finally, use introspection to map between type of 
the object and the list of editable parameters. PEP 246 adaption might be 
useful here, since it would let you break the tight coupling between types and 
their parameters:
	def OnPickObject(self, evt):
		obj = evt.object
		params = adapt(obj, IObjectParameters, None)
		if params is not None:
			frame = ObjectEditorFrame(self, params)
			frame.Show()
	# ...imagine that ObjectEditorFrame looks something like right hand
	# side of the window on page 15 of
	# 	http://www.python.org/pycon/papers/chaco.pdf
	# except that is automagically builds its contents based on the
	# its IObjectParameters argument.
It might be a good idea to bug John about matplotlib transitioning to using
the Traits package from Enthough, which would take care of managing the object
parameters for you. They developed it for use in their Chaco plotting library,
which went MIA shortly after release.
> 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.
A toolbar that pops up via mouseover would be pretty impressive, but I can't 
think of a way to implement it off the top of my head. I'm not sure what you 
mean by "scrollable axes". Do you mean pannning, the way pylab plots work? 
Crosshair cursors are easy and coordinate readout are pretty easy and I 
believe they already work in both MPlot and WxMpl. Likewise 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.
I'm not sure what to recommend. Merging MPlot and WxMpl so that MPlot uses 
WxMpl for rendering and plot-level user interactions like zooming would be one 
way to start. I think you'd probably be better off going with a more dynamic 
approach to parameter editing, since it would be a bit more work up front but 
a lot less work to add plot types. If done right, the object picking and 
parameters stuff could even be backend independent.
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

>You need to understand that this is simply how free software works: =
when=20
>someone needs something badly enough _for themselves_, they get off =
their butt=20
>and write it. Then it's available for all to use (if released). I did =
that=20
>for interactive mpl support over a year ago, so that's why it's been=20
>prominently displayed for a while (and this _is_ useful to a lot of =
people,=20
>since quick-and-dirty interactive data analysis is a very common task). =
 Now=20
>you guys are doing the same for WX tools, and that's fantastic. I'm =
sure=20
>John will advertise it equally prominently.
>So relax, nobody is trying to be misleading about anything, we're all =
here=20
>simply working on what each of us needs, so the evolution process is =
rather=20
>inhomogeneous.
Perhaps I hadn't been clear. I'm not complaining of features missing. =
I'm just saying that, for example, the docs are misleading, because they =
focus on pylab when they would have to show both pylab and the OO =
interface. Pylab is a wonderful feature of MPL, but it's not the only =
one. I'm relaxed, I just feel that it's quite sad to focus only on pylab =
when users would like to know about the beautiful programming interface =
that already exists and that lies beneath.
m.

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

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

 You guys are having a great discussion about using matplotlib with
wxWindows in many different ways. I just wanted to chime in and let
any other lurkers know that matplotlib can also be easily embedded in
GTK apps with PyGTK. I've done this several times to make small
applications that help me in data analysis. The examples directory is
a great place to start.
 I don't have any experience with matplotlib+PyGTK on platforms
other than Linux. (Ahh, the joys of scientific programming: now
Windows.) Perhaps wxWindows handles cross-platform apps better, I'm
not qualified to answer.
 If other people are interested, I could try writing up a Wiki page
with one of my small "matplotlib embedded in a GTK app" programs.
--
 -- Graeme
 gra...@gm...

> -----Original Message-----
> From: massimo sandal [mailto:mas...@un...]=20
> Sent: Friday, December 02, 2005 10:47 AM
> To: Henshaw, Andy
> Cc: mat...@li...
> Subject: Re: [Matplotlib-users] advice on writing an application
>=20
> > [...]
> > I'm certainly willing and able to contribute to this=20
> development. I'm=20
> > conflicted as to which code base to begin with, however.
>=20
> Tell me what do you think too about the "stack model" I=20
> proposed a couple of posts above. I'd like to help with it,=20
> but I'm still very much in the learning phase...
>=20
> Massimo
Not sure, at this point, but it seems to be a reasonable approach.
You'd need a stacking model that allows the end-programmer to cleanly
access the functionality of the lower levels, however.
Andy Henshaw
Georgia Tech Research Institute

> Sorry to horn in here, but this is a topic in which I am very
> interested. What I want is both of these solutions combined! I'd like
> to have the full power of MatPlotLib when I'm developing my
> applications, but, I'd also like to have (nearly) that full power
> presented to the user for further customization and interaction. I'd
> like to have many more features available to the user than are currently
> provided by Mplot, but when I'm coding I'd like to be able to drop in a
> complete panel without having to do the coding that I'd need to do with
> WxMPL.
> [...] 
> I'm certainly willing and able to contribute to this development. I'm
> conflicted as to which code base to begin with, however.
Tell me what do you think too about the "stack model" I proposed a 
couple of posts above. I'd like to help with it, but I'm still very much 
in the learning phase...
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

>On 12/01/05 16:13, Matt Newville wrote:
>> Here's what I think the fundamental differences are. Maybe Ken can=20
>> give an opinion too.
> My take on things is that WxMpl and MPlot solve two different
problems. =20
> WxMpl is intended to be a FigureCanvasWxAgg that has some
pointy-clicky=20
> user interactions (e.g. zoom) built in. I gather that Matt considers=20
> it "focused on the programmer/script writer, not on the end user=20
> 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.
>=20
> I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his=20
> approach wasn't solving my problem: I was thrilled what matplotlib=20
> and wanted *all* of it to Just Work with wxPython. Allowing users=20
> to edit plots was less important to me than supporting as many kinds
> of plots as possible. By focusing on adding user interaction to=20
> FigureCanvasWxAgg I was able to support all of matplotlib's OO API
> in one fell swoop.
Sorry to horn in here, but this is a topic in which I am very
interested. What I want is both of these solutions combined! I'd like
to have the full power of MatPlotLib when I'm developing my
applications, but, I'd also like to have (nearly) that full power
presented to the user for further customization and interaction. I'd
like to have many more features available to the user than are currently
provided by Mplot, but when I'm coding I'd like to be able to drop in a
complete panel without having to do the coding that I'd need to do with
WxMPL.
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.
Andrew Henshaw
Georgia Tech Research Institute

> 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

>>>>> "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

Hi,
interpolation seems not to be supported for pcolor plots. Is that true? I want
to plot nonaequidistant gridded data, so imshow is not the right choice. Using
contourf with a large number of contour levels works fine but the eps output is
huge. I'd prefer to have the image embedded as bitmap in an eps, that's why I'd
like to use pcolor.
Regards, Christian

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

Dear members
I have done a quick search of the archives, but did not find anything
information regarding my problem (or at least to my knowledge). I have
written an application using wxPython and I am using embedded matplotlib
plotting to show some of the generated results. This I have done fairly
similar to the embedding in wx examples presented for matplotlib and it
works fine with little effort. So far so good.
My problem however is that I am unable to change my font style (it seems
to be Times New Roman or similar and I want it to be Arial) for the
labels ext., even though I can change just about everything else there
is to change, including font size, the coverage of the canvas by the
figure and so forth. This I do be merely changing the matplotlibrc file
copied to my application directory. Are there any suggestions or may be
a request for more detail information regarding my problem?
Regards
Johann Strauss

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