matplotlib-devel Mailing List for matplotlib (Page 6)

On Wed, Jul 1, 2009 at 9:51 PM, Andrew Straw<str...@as...> 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 by passing it a
>> subfigure instance, like the way axes work.
>>
>> Also, Chaco has the notion of containers, in which you can stack plots or
>> other containers. They have an additional feature which is that they
>> enable you to stack plot (these would be axes, in matplotlib terms) and
>> do an automatic layout of the plots. Very handy to have an extensible
>> canvas to display information on. Some sparse documentation:
>> http://code.enthought.com/projects/chaco/docs/html/api/containers.html
>>
>> I have been trying to find time to think about this for more than a year,
>> and haven't. This is why I am sending unfinished thoughts. I do believe
>> more thinking has to be done, and the subfigure proposition may not hold
>> at all. Also, I fear I do not have time to implement this.
>>
> I also have some not very fleshed out thoughts: my main feeling about
> MPL is that there's just too much layout happening to keep using the
> non-systematic delegation/notification "system" currently in place while
> allowing the devs to maintain their sanity and day jobs. I don't mean to
> disparage MPL -- it is quite a fantastic piece of code -- but there is a
> lack of abstraction of layout hierarchies and layout dependencies that
> makes development difficult.
>
> Therefore, I'd suggest that before adding on too many more nice
> features, we revisit the core layout and delegation system -- in the end
> it will make everything much easier. So, perhaps a useful thing would be
> for as many MPL devs as possible to sit together and discuss how we
> could do this. My thought right now would be to investigate the use of
> traits to codify the layout abstractions.
>
> Any effort like this will also obviously benefit from having an
> extensive test suite. I think all that's needed to get the tests at
> http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone
> checks in new images made with the current MPL. I'd like to do this, but
> I'm really short on time at the moment. So, please, someone -- beat me
> to it -- it won't be hard!
>
> Those are my 2 cents. Hope to see you all at SciPy 2009!
>
> -Andrew
While we're dreaming big re-architecting dreams, I'll throw out an
idea related to Gael's suggestion: artist containers at the sub-axis
level. This would be a drawable / hideable container for an arbitrary
grouping of Artists that could be directly added to one (or more)
Axes. For those familiar with IDL, the IDLgrContainer in their object
graphics system is what I have in mind.
I also concur with Andrew's assessment that interactive and layout
event handling is holding back some extra fun in interactive apps. I
have mixed feelings about using Traits; in my experience with writing
(only one) app, I felt like I had to subsume everything, my data
modeling included, under the Traits paradigm, such that I was no
longer writing Python but Traits. I found it very hard to include
other data objects created by other libraries without making them
Traitified, too. This could be a knowledge gap on my part, of course.
David Beazley's course on coroutines
(http://www.dabeaz.com/coroutines/index.html, see esp. Part 3) and
this talk (http://carlfk.blip.tv/file/2232349) on asynchronous vs.
threaded multitasking both have some interesting thoughts on
standard-library ways to model OS-like behaviors such as event
handling.
Thanks,
Eric

Hi Pierre,
On Sat, Jun 6, 2009 at 11:49 AM, Pierre Raybaut <co...@py...>wrote:
> 2009年4月28日 Dave Peterson <dpe...@en...>:
> > Darren Dale wrote:
> >
> > On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut <co...@py...>
> > wrote:
> >>
> >> 2009年4月28日 John Hunter <jd...@gm...>:
> >> >
> >> >
> >> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut <co...@py...
> >
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> I would like to contribute to matplotlib with this enhancement for
> the
> >> >> PyQt4 backend: the idea is to add a toolbar button to configure
> figure
> >> >> options (axes, curves, ...).
> >> >>
> >> >> It's based on a tiny module called formlayout to generate PyQt4 form
> >> >> dialog automatically.
> >> >>
> >> >> Some screenshots:
> >> >> http://code.google.com/p/formlayout/
> >> >>
> >> >> So, if you're interested (all the following is GPL2):
> >> >>
> >> >> *matplotlib patch*
> >> >>
> >> >> In FigureManagerQT.__init__, added:
> >> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
> >> >>
> >> >> In NavigationToolbar2QT._init_toolbar, added:
> >> >> a = self.addAction(self._icon("customize.png"), 'Customize',
> >> >> self.edit_parameters)
> >> >> a.setToolTip('Edit curves line and axes parameters')
> >> >>
> >> >> Added the following method in NavigationToolbar2QT:
> >> >> def edit_parameters(self):
> >> >> from figureoptions import figure_edit
> >> >> figure_edit(self.canvas, self)
> >> >>
> >> >> *additionnal modules and data*
> >> >>
> >> >> formlayout.py (http://code.google.com/p/formlayout/)
> >> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
> >> >> customize.png (http://code.google.com/p/PyQtShell/)
> >> >
> >> > Hi Pierre -- this looks very nice (the last link is broken though , I
> >> > get a
> >> > 404 error). We would be happy to include this in matplotlib or as a
> >>
> >> Here is the last link:
> >> http://code.google.com/p/pyqtshell/
> >>
> >> > toolkit. To contribute it to to mpl, the license needs to be
> >> > matplotlib
> >> > compatible
> >> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses)
> but
> >> > we
> >> > have more licensing flexibility in a toolkit, though we prefer to keep
> >> > everything BSD compatible where possible. And of course you would
> need
> >> > to
> >> > agree to maintain it :-) but I think many users would appreciate a GUI
> >> > plot
> >> > configuration dialog.
> >>
> >> I was not aware of this license restriction in matplotlib... I fully
> >> understand the motivation, of course, but still: I wrote all this on
> >> my free time which means no PyQt4 commercial license, so it can't be
> >> anything but GPL. Sorry...
> >
> > I think you have overlooked a subtlety of PyQt4's license. The author of
> > PyQt4 wrote on the enthought-dev mailing list:
> >
> > "PyQt is GPL but has exceptions that allow it to be used with BSD code -
> > hence it's Ok for TraitsBackendQt to be BSD.
> >
> > However, the exception imposes additional conditions which, to all
> intents
> > and purposes, infects the code with the GPL. To be fair to people that
> > should be made clear in any text.
> >
> > It's still a good idea for TraitsBackendQt to use a BSD license because
> it
> > allows commercial (ie. non-GPL) users to use it without problems."
> >
> > Darren
> >
> > I think it might be worth contacting the PyQt folks (Phil Thompson) about
> > this. I think there might be some differences here because Phil was the
> > author of TraitsBackendQt and thus his efforts didn't quite fall under
> the
> > "develop under a free license, your results needs to be GPL" clause
> Qt/PyQt
> > have in their licensing.
> >
> > -- Dave
> >
> >
>
> Hi all,
>
> Dave, you are absolutely right.
>
> Last week-end, I found myself surfing on PyQt's website and I told to
> myself: what about re-reading the license? (always a pleasure) And
> surprisingly, I found out that anyone using the GPL version of PyQt
> can release source code under a very permissive license (like MIT or
> BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
> part of the distributed package (otherwise the whole package has to be
> licensed under GPL) - and with other little restrictions. It was a
> surprise because I've read here and there a lot of things on PyQt
> license and the general idea was "if you write PyQt code without the
> commercial license, your code *must* be licensed under GPL" - I can
> tell now that it's not true (to be absolutely certain about it, I even
> asked to Phil Thompson to confirm this, and he did).
>
> So, I switched all the code I was referring to in my original e-mail
> to MIT license.
> I guess now it could be integrated to matplotlib Qt4 backend?
>
> formlayout (generate option dialogs):
> http://code.google.com/p/formlayout/
>
> pydee (IDE which integrates matplotlib and the option dialog):
> http://code.google.com/p/pydee/
> Meanwhile, thanks to the brand new Google-code Mercurial support, you
> may browse the source code if you like:
>
> http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
>
Do you have the customize image in svg, and do you have the right to release
it under the terms of the matplotlib license? Would you be willing to
provide feedback in the future if problems are reported?
Darren

Hi,
I've just wanted to notify you about a small annoyance:
FigureCanvasGTK does not set the guiEvent attribute of the generated 
events to the original GDK event but leaves it to None. This is 
trivial to fix by just adding 'event' to the relevant calls to the 
event handlers of FigureCanvasBase.
Please fix it, my code depends on it :)
Henning

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 by passing it a
> subfigure instance, like the way axes work.
>
> Also, Chaco has the notion of containers, in which you can stack plots or
> other containers. They have an additional feature which is that they
> enable you to stack plot (these would be axes, in matplotlib terms) and
> do an automatic layout of the plots. Very handy to have an extensible
> canvas to display information on. Some sparse documentation:
> http://code.enthought.com/projects/chaco/docs/html/api/containers.html
>
> I have been trying to find time to think about this for more than a year,
> and haven't. This is why I am sending unfinished thoughts. I do believe
> more thinking has to be done, and the subfigure proposition may not hold
> at all. Also, I fear I do not have time to implement this.
> 
I also have some not very fleshed out thoughts: my main feeling about
MPL is that there's just too much layout happening to keep using the
non-systematic delegation/notification "system" currently in place while
allowing the devs to maintain their sanity and day jobs. I don't mean to
disparage MPL -- it is quite a fantastic piece of code -- but there is a
lack of abstraction of layout hierarchies and layout dependencies that
makes development difficult.
Therefore, I'd suggest that before adding on too many more nice
features, we revisit the core layout and delegation system -- in the end
it will make everything much easier. So, perhaps a useful thing would be
for as many MPL devs as possible to sit together and discuss how we
could do this. My thought right now would be to investigate the use of
traits to codify the layout abstractions.
Any effort like this will also obviously benefit from having an
extensive test suite. I think all that's needed to get the tests at
http://mpl-buildbot.code.astraw.com/waterfall to pass is that someone
checks in new images made with the current MPL. I'd like to do this, but
I'm really short on time at the moment. So, please, someone -- beat me
to it -- it won't be hard!
Those are my 2 cents. Hope to see you all at SciPy 2009!
-Andrew

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 by passing it a
subfigure instance, like the way axes work.
Also, Chaco has the notion of containers, in which you can stack plots or
other containers. They have an additional feature which is that they
enable you to stack plot (these would be axes, in matplotlib terms) and
do an automatic layout of the plots. Very handy to have an extensible
canvas to display information on. Some sparse documentation:
http://code.enthought.com/projects/chaco/docs/html/api/containers.html
I have been trying to find time to think about this for more than a year,
and haven't. This is why I am sending unfinished thoughts. I do believe
more thinking has to be done, and the subfigure proposition may not hold
at all. Also, I fear I do not have time to implement this.
My 2 cents,
Gaël

John Hunter wrote:
> Also, we have raised a few hundred dollars in donations, so we could
> either fly a worthy person out who might not otherwise be able to
> attend, or pay for sprint registration for someone not getting
> institutional support. Or at least provide coffee, doughnuts, pizza
> and beer as fuel for participants. Fernando has also informed me
> there may be some travel and conference money from other sources for
> student developers so please email me us list if you are interested.
> 
One small correction: sprints are free to attend. The only registration 
costs are for the tutorials and conference itself.
-- Dave

After a two year hiatus where I inadvertently scheduled my travel
plans to overlap scipy, I will finally be able to make it to the scipy
conference this year, and plan to make up for lost time by coming
early to lead a tutorial on advanced mpl usage, stay through the
conference, and if any of you are interested, do a sprint. There are
lots of interesting things we can work on: refactoring the ticks to
work nicely with the new spines, pushing forward on the documentation,
optimizing stuff that is too slow or memory intensive, improving the
animation API and backend support, gradients, ....
Anyone interested? And if so, feel free to suggest topics or weigh in
on some I listed.
Also, if any of you will be there early for the tutorials, it would be
great to have some help from floaters, people who walk around the
room and help people who get stuck during the hands-on examples or
teachers, people who lead part of the tutorial. In particular,
Michael could do a segment on transforms and paths, JJ could do a
segment on all his fancy arrows, boxes, annotations, etc, Andrew on
his spines, Reinier on mplot3d, etc... I will probably cover all of
these even if you can't attend or don't want to teach, but it is best
ot hear from the experts. And if anyone not mentioned wants to
contribute a segment, that would be great -- just let me know what it
is. The tutorial is 2 hours and focuses on advanced mpl usage so I
want to avoid the everyday stuff and focus on transforms, paths, event
handling, animation, the newer features (spines, fancy*, mplot3d) and
everything else I am currently forgetting.
Also, we have raised a few hundred dollars in donations, so we could
either fly a worthy person out who might not otherwise be able to
attend, or pay for sprint registration for someone not getting
institutional support. Or at least provide coffee, doughnuts, pizza
and beer as fuel for participants. Fernando has also informed me
there may be some travel and conference money from other sources for
student developers so please email me us list if you are interested.
JDH

Hi,
On Mon, Jun 1, 2009 at 10:20 PM, Fernando Perez<fpe...@gm...> wrote:
> The time for the Scipy'09 conference is rapidly approaching, and we
> would like to both announce the plan for tutorials and solicit
> feedback from everyone on topics of interest.
rather than rehash much here, where it's not easy to paste a table,
I've posted a note with the poll results here:
http://fdoperez.blogspot.com/2009/06/scipy-advanced-tutorials-results.html
The short and plain-text-friendly version is the final topic ranking:
1	Advanced topics in matplotlib use
2	Advanced numpy
3	Designing scientific interfaces with Traits
4	Mayavi/TVTK
5	Cython
6	Symbolic computing with sympy
7	Statistics with Scipy
8	Using GPUs with PyCUDA
9	Testing strategies for scientific codes
10	Parallel computing in Python and mpi4py
11	Sparse Linear Algebra with Scipy
12	Structured and record arrays in numpy
13	Design patterns for efficient iterator-based scientific codes
14	Sage
15	The TimeSeries scikit
16	Hermes: high order Finite Element Methods
17	Graph theory with NetworkX
We're currently contacting speakers, and we'll let you know once a
final list is made with confirmed speakers.
Cheers,
f