[SciPy-dev] Re: [AstroPy] Python version of IDL Astron library

[John Hunter]

>>>>> "eric" == eric jones <eric at enthought.com> writes:
   
    Fernando> Perhaps we all would have wanted J. Hunter to hack on Chaco for
    Fernando> the last year.  But at least now we have two viable systems,
    Fernando> one which works today and the other which is building a very
    Fernando> solid foundation for the future.  I can only see this as a good
    Fernando> thing in the long run.

When I was shopping for plotting libraries back in the day, I did give
serious consideration to chaco.  My needs were fairly specific: to
find a high quality 2D lib I could embed in a GTK app, which Chaco did
not support.  It would have been a better use of community resources
if I had extended Chaco to do what I needed, but at the time I was
primarily considering the best use of *my resources*.  It's a blessing
and a partly a curse that python is so powerful, easy and fun to
program that it can sometimes be easier to roll your own solution than
extend someone else's.  My goals at the time were limited and I wasn't
thinking about developing a general purpose plotting library.
Hindsight, as they say, is twenty-twenty.

    eric> This is exactly what I was trying to say, but perhaps not as
    eric> well.  Having a solution sooner fixes many issues, and that
    eric> is very beneficial for the reasons you mention.  However,
    eric> from a strictly person-hours required to reach the long term
    eric> goal of a utopian plotting toolkit, it would be more
    eric> efficient to have all hands working on the same project.
    eric> There are alwasy tradeoffs, and I think that the current
    eric> situation (two packages) is not bad at all.

Yep, and as you mentioned in your other post, there are certainly
possibilities for cross-pollination.  My first priority vis-a-vis
matplotlib is to add the two remaining essential plot types: contour
and polar.  After that, I plan to make some changes enhancing the
core.  Here are a few partially baked ideas that I'm ruminating over

  rendering: matplotlib still uses a variant of the gtk drawing model
  in the backend, which doesn't support arbitrary clipping paths,
  even-odd filling rules and the like.  So I plan at some point to
  introduce a new drawing model and perhaps kiva would fit the bill.
  If matplotlib and chaco both used the same backend API then efforts
  on the backend of one package would be useful to the other.  It
  would also make it easier to port frontend code from one package to
  another.  Along these lines, I wonder how satisfied you are with the
  kiva API and implementation.  I'm not sure this is the route I want
  to go, but it has come up in discussions with Perry and Paul on a
  couple of occasions and clearly has merit.

  envisage: I definitely have a need for a scientific application
  framework, and envisage and enable looked awesome; enable in
  particular addresses a lot of problems I keep encountering trying to
  support basic functionality across GUIs.  I talked to David and
  Martin at scipy about the possibility of plugging matplotlib into
  envisage, and they were supportive of the concept but I gathered
  from them that the envisage API is still somewhat fluid.  When this
  settles, if you guys are able to provide a 2D canvas/plotting API
  for envisage, I would be happy to do the work to port matplotlib to
  it.

  traits: I thought the new traits mode you presented at scipy looked
  great, and there has been interest for some time in using them in
  matplotlib.  Since you've already ported these to wxpython and tk
  (right?), my guess is that I could add pygtk support, and the author
  of the matplotlib fltk backend might do the same for fltk, which
  would at least cover the spectrum of current matplotlib backends.
  Using traits in matplotlib might also help with matplotlib /
  envisage integration down the road.
  
  mathtext: As I mentioned at scipy, I would like to improve the
  mathtext layout engine.  It's already decent, but there are
  definitely areas where it could be better.  One good idea that came
  up at scipy was to use TeX where available, and I'm looking in to
  that.  Almost all of the permutations off TeX that I've found thus
  far are GPL'd, which is unfortunate in my view because Knuth
  released TeX under an extremely permissive license -- basically the
  only restriction is that if you change the src, you must rename the
  file.  In any case, whether I improve the matplotlib layout engine,
  expose tex, or both, chaco could probably reuse some of this code
  for mathematical expressions.

Cheers!
JDH