Re: [Matplotlib-users] object picker legend and axis

[John H. <jdh...@ac...>]

>>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <Jean-Baptiste.cazier@d=
ecode.is> writes:

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

  * Font standardization across backends.  With a common image
    renderer that supports freetype, all the GUIs can have freetype
    support with common font names.
=20
  * 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
FigureCanvas API.

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

JDH