[SciPy-dev] Re: [AstroPy] Python version of IDL Astron library
jdhunter at ace.bsd.uchicago.edu
Tue Sep 14 12:20:55 CDT 2004
>>>>> "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
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.
More information about the Scipy-dev