I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 . I'm
attaching the patches and an image created by the new example.
This is a somewhat invasive change into the core of the axis rendering
code, so I'm hereby requesting a review before committing it into the
code base. In particular, I dropped the idea of using Traits in MPL not
because I think it's a bad idea, but because that would involve more
substantial changes.
Anyhow, I'm attaching the proposed implementation as a series of
patches. If the general form of this looks OK, I'd write up doc strings
and a CHANGELOG entry and commit it. Should I wait until after the trunk
release?
Please let me know what you think. All the examples run with
exaples/tests/backend_driver.py still seem to give OK results, and the
test suite raises a few more failures, but these appear due to
(sub)pixel shifts in text rendering rather than anything more severe.
-Andrew
0001-Initial-implementation-of-dropped-spines.patch (13.8 KB)
0002-non-cartesian-axes-pass-through-for-dropped-spines.patch (7.38 KB)
0003-add-example-of-dropped-spines.patch (2.74 KB)
Andrew Straw wrote:
I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
Performance trade-offs in the flight initiation of Drosophila | Journal of Experimental Biology | The Company of Biologists . I'm
attaching the patches and an image created by the new example.
This is a somewhat invasive change into the core of the axis rendering
code, so I'm hereby requesting a review before committing it into the
code base. In particular, I dropped the idea of using Traits in MPL not
because I think it's a bad idea, but because that would involve more
substantial changes.
Anyhow, I'm attaching the proposed implementation as a series of
patches. If the general form of this looks OK, I'd write up doc strings
and a CHANGELOG entry and commit it. Should I wait until after the trunk
release?
Please let me know what you think. All the examples run with
exaples/tests/backend_driver.py still seem to give OK results, and the
test suite raises a few more failures, but these appear due to
(sub)pixel shifts in text rendering rather than anything more severe.
-Andrew
Andrew,
It looks like that nicely addresses a frequent request. Great! I haven't looked closely enough yet to see how it all works, but one immediate suggestion is that the adjust_spines function in your example looks like something that should be modified a bit and turned into an axes method with the usual pyplot wrapper. That is a fine point, of course, that can be deferred.
It looks like the offset is defined as positive outward from center of the plot. Are negative values allowed, so the spine goes through the middle of the plot, for example?
The name "spine" threw me off for a while; but I guess that is a reasonable description for a line with ticks. "Axis" and "Scale" are already taken, so maybe "spine" is as good as we can find. "Dropped spine" sounds like a painful medical condition... Oh, well...
Eric
Hey Andrew -- this is really excellent. The lack of support for spine
placement is one of the things that has been mentally holding me back
from releasing mpl as 1.0, so by all means commit it. I did read
through the patch, and it looks like a clean implementation so I don't
have any specific suggestions. I would like to see a 'xcenter'or
'ycenter' (or whatver name works best) option in addition to the
'left', 'right', 'top' and 'bottom' so we can easily support things
like Mathematica/Sage style spines
http://webscripts.softpedia.com/scriptScreenshots/SAGE-Screenshots-27855.html
Do you think you could add this fairly easily? Also, it would be nice
to have some simple configuration options, perhaps a few default
themes, so one could easily switch between them, and probably rc
support for a default theme. The theme might specify both the spine
placement as well as the tick in/out/center placement. None of this
needs to go in ahead of the initial commit though.
Thanks!
JDH
···
On Thu, May 21, 2009 at 7:47 PM, Eric Firing <efiring@...229...> wrote:
Andrew Straw wrote:
I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
Performance trade-offs in the flight initiation of Drosophila | Journal of Experimental Biology | The Company of Biologists . I'm
attaching the patches and an image created by the new example.
It looks like that nicely addresses a frequent request. Great! I
haven't looked closely enough yet to see how it all works, but one
immediate suggestion is that the adjust_spines function in your example
looks like something that should be modified a bit and turned into an
axes method with the usual pyplot wrapper. That is a fine point, of
course, that can be deferred.
It looks like the offset is defined as positive outward from center of
the plot. Are negative values allowed, so the spine goes through the
middle of the plot, for example?
I just had a quick at the patch and it looks good.
I have two minor issues.
1) API change in Axes.get_xaxis_transform & get_yaxis_transform.
The default keyword argument which=None raises an exception. Maybe
you meant which="grid"?
2) Axes.frame
Is it okay to simply drop this attribute? Any code that access this
attribute will raise an exception. For example, some of my code in
mpl_toolkits.axes_grid access this attribute, although a fix would be
very trivial.
Regards,
-JJ
···
On Thu, May 21, 2009 at 8:06 PM, Andrew Straw <strawman@...36...> wrote:
I've implemented initial support for "dropped spines". This is motivated
by the ability to draw figures that look like
Performance trade-offs in the flight initiation of Drosophila | Journal of Experimental Biology | The Company of Biologists . I'm
attaching the patches and an image created by the new example.
This is a somewhat invasive change into the core of the axis rendering
code, so I'm hereby requesting a review before committing it into the
code base. In particular, I dropped the idea of using Traits in MPL not
because I think it's a bad idea, but because that would involve more
substantial changes.
Anyhow, I'm attaching the proposed implementation as a series of
patches. If the general form of this looks OK, I'd write up doc strings
and a CHANGELOG entry and commit it. Should I wait until after the trunk
release?
Please let me know what you think. All the examples run with
exaples/tests/backend_driver.py still seem to give OK results, and the
test suite raises a few more failures, but these appear due to
(sub)pixel shifts in text rendering rather than anything more severe.
-Andrew
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
We can drop it - there never was a documented reference to it, no
public method, etc, so it is safely considered mostly "internal
code", and in the global scheme is comparatively new code (and on a
quick grepping did not see any examples using it in the pylab_examples
or api dirs). I don't think it will impact many users, and anyone who
was trying to manipulate the frame directly can easily update their
code. We should just have a little transition cheatsheet in the
API_CHANGES section describing the removal.
We *could* override getattr and raise a suitable warning pointing to
the spine docs, if people think that is needed, but overriding getattr
often leads to unintentional bugs.
JDH
···
On Thu, May 21, 2009 at 10:08 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:
2) Axes.frame
Is it okay to simply drop this attribute? Any code that access this
attribute will raise an exception. For example, some of my code in
mpl_toolkits.axes_grid access this attribute, although a fix would be
very trivial.
Based on Jae-Joon's comment, I was thinking of making .frame a property
that raised an Error describing to get .spines instead... That avoids
the getattr issues, but I think depends on Artist being a new style class.
This is a much better solution, one I hadn't thought of, so go with
it. Artist is already a newstyle class, so no problems there.
(Thanks to all for the responses... I'm acting on them and will
incorporate most or all of the suggestions.)
Excellent.
JDH
···
On Fri, May 22, 2009 at 9:35 AM, Andrew Straw <strawman@...36...> wrote: