Personally, I think traits must be kept out of MPL, for three main reasons:
1. As Eric Bruning points out, while traits is a very powerful tool,
it also closes a lot of doors by forcing everything to be written in a
trait-like fashion for it to play nice with everything else. While
this is great for many applications, I think it does not necessarily
belong everywhere, particularly given a tendancy to quickly snowball
in complexity (not to mention any new people that want to contribute
code have an extra thick manual to read).
2. Installation of traits or traitsgui should not be a necessity for
MPL... perhaps this will change in the future, but it's currently a
far bigger task to get traits and traits UI working on an arbitrary
system than it is to get MPL up and running (at least, that's been my
experience in a number of different settings).
3. Chaco - my general mindset on this is that Chaco is great for
plotting any and everything in a traits gui, but MPL is much better
for the quickcalculations and plots that I make every day as a
scientist. When a critical mass is reached it becomes better to
integrate a tool into a GUI app, MPL becomes more difficult to manage
and chaco is a better tool. But I think it makes a lot of sense to
leverage MPL most as the wonderful "quick-and-dirty" command-line
interactive plotting environment that it is rather than making it
application-centric, which is where I can envision it going as soon as
it has to run with traits.
Now a great idea would be to include optional support for things like
setting configuration files from a traits interface - I know I've seen
talk of doing this for matplotlibrc at some point, and I'd definitely
use that. Simlarly, some sort of traits-level extension to support
more interactive plots and better layout seems like it could be done
without requiring the core to use traits.
As for the question of new directions to go: One thing I would like to
see is a decent, simple 3D package in the core - nothing fancy (mayavi
is great if you want to get fancy), but just something that makes
great publication-quality figures with a quick and simple pylab-like
interface. That's the main thing I have no good response for when
people are contemplating switching to python/numpy/MPL. I also think
it might be neat to implement auto-generating function plots - that
is, plots where one of the axes is generated by a function at a
resolution that scales as you change the plot. I've seen some chaco
demos of something like this, but it's rather complicated to implement
- a function like pyplot.plotfunc(func,'--b',initialrange=(-1,1)) that
does exactly this would be a wonderful capability.
This may be more a user perspective than a "dev" perspective, but
still, there it is.
On Thu, Jul 2, 2009 at 10:45 AM, Eric Bruning wrote:
> On Wed, Jul 1, 2009 at 9:51 PM, Andrew Straw wrote:
>> Gael Varoquaux wrote:
>>> On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote:
>>>
Anyone interested? And if so, feel free to suggest topics or weigh in
on some I listed.
>>>
>>> Actually, I have something I would like to discuss, but never really
>>> could pull myself together to do it. I don't have time right now, but I
>>> am still going to jot down the ideas.
>>>
>>> The axes and figure paradigm inherited from matlab works well for simple
>>> things, but when I want to more complex layouts, I actually end up
>>> struggling with calls to axes with numerical parameters to adjust. In
>>> addition, if I have a function that creates a plot with multiple axes,
>>> like the figure on:
>>> http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html
>>> I may want to reuse that function to create more complex figures,
>>> stacking several of these views, with possibly other plots.
>>>
>>> It seems to me having a level of granularity between the figure, and the
>>> axes would help me a lot achieving these goals. I haven't had time to
>>> hash out an API, or even solid concepts. For people who know LaTeX well,
>>> let me draw an analogy: the figure is the page, the axis is the
>>> character, what we are lacking in a 'minipage'. I would like a container
>>> that can be stacked into a figure, and that can either hold axes, or
>>> similar containers. That way, I could specify subplot, or axis relative
>>> to this container, rather than relative to the whole figure, and it makes
>>> it really easy for me to insert figures in larger figures.
>>>
>>> One possible API would be 'subfigure', which would have a signature
>>> similar to 'axes', but of course things would need to be thought a bit
>>> more in detail: do we want clf to erase the figure and not the subfigure?
>>> I believe so. Do we want subplot to divide the subfigure, rather than the
>>> figure? I believe so too. How do we go back to full figure without
>>> erasing the subfigures it contains? I think subfigure(None) might work.
>>> How do I select a subfigure I already created? Maybe
