>>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <Jean-Baptiste.cazier@...=
Jean-Baptiste> S=E6ll ! Thanks for the info and update. I upgaded
Jean-Baptiste> my library and my program. The dramatic change of
Jean-Baptiste> API was a bit painful, but the new syntax is more
Jean-Baptiste> clear. Do you have any idea when you will hav
Jean-Baptiste> reached a stable version in general and in term of
Jean-Baptiste> version ?
It has been a bit painful, my apologies; I still have one application
to port myself. But it was necessary. matplotlib is undergoing
active development. The basic idea is to write a backend for a
powerful image renderer, http://antigrain.com or libart , and use that
backend to draw to the GUIs. Rather than each GUI implementing it's
own drawing, I'm moving to one high quality image renderer that will
draw to the GUI.
Why? Four major benefits
* Easier maintenance: when I want to add a feature, I add it to the
image backend and all the GUIs automatically benefit.
* Enhanced drawing capabilities - the GUIs don't support a lot of
the more sophisticated drawing capabilities, eg, paths from PS and
SVG, or alpha blending, or gouraud shading. The agg backend
supports all of these, and therefore by extension, so will the
* Font standardization across backends. With a common image
renderer that supports freetype, all the GUIs can have freetype
support with common font names.
* Ease of plain old image integration with figures - 2D image plots,
like pcolor, will become very fast and very pretty.
Any solution along these lines will be performance competitive with
native GUI and work on all major platforms (win32, osx, linux, unix)
or we won't do it.
In order to do this right, I needed the Figure class (and all it's
children) to be totally backend independent. So a WX figure can
render to a postscript renderer, or an agg renderer, or a gd renderer,
or a libart renderer. In earlier releases of matplotlib, the AxisText
and Figure classes were tied up in the backend.
I have made it a policy not to predict a stable API because I don't
want to go back on my word. That said, I think the existing design is
clean and I am happy with it. I would not have said that a month ago.
I don't anticipate any major changes to the Figure API or the
Changes I do expect to see in the near future are
* the addition of GTK/AGG, WX/AGG and Tkinter/AGG backends. These
will be optional so for those of you who want to stay with the
classic GUI backends you can. But I would encourage you to move
over at that time since you'll get better drawing, more
sophisticated plots, etc... I will probably add a matplotlibrc
file in which you can select your default backend. This will be an
almost trivial API port, if you choose to. This will probably be
around matplotlib-0.6 (1-2 months).
* Addition of path drawing methods in the renderer API. This will
allow for the more sophisticated that state dependent paths
support. If you don't work directly with the renderer, it won't
affect you. It's mainly for backend implementers.
As for API stability in general, I have 2 additional thoughts.
* for the matlab interface, if it's matlab compatible it's 99% likely
to be stable. We've made minor departures from this when there was
clearly a better way to do it, but it's a good rule of thumb.
* As with many projects, I think the 1.0 release should guarantee
some API stability. I predict you'll see a pretty stable API until