ENH: add axisbelow option 'line', make it the default #6287
Conversation
| @@ -981,7 +992,7 @@ def validate_animation_writer_path(p): | |||
| 'errorbar.capsize': [0, validate_float], | |||
|
|
|||
| # axes props | |||
| 'axes.axisbelow': [False, validate_bool], | |||
| 'axes.axisbelow': ['line', validate_axisbelow], | |||
There was a problem hiding this comment.
also need to change in the template
|
I am moderately 👍 on this. Would it be better to let the rcparam be a float ? |
5af57a7 to
1956510
Compare
|
I thought about the float option, but using strings fits better with the (perhaps unfortunate) existing name of the parameter/kwarg. "axisbelow line" makes a little bit of sense; "axisbelow 1.5" doesn't. |
|
There are 3 image failures involving minuscule differences. In the one I reproduced, I can't even see anything other than solid black in the diff image. I would not expect this PR to affect any images because the classic style is unchanged. |
|
I have been seeing tiny image comparison failures locally. The diff images On Sun, Apr 10, 2016 at 11:07 PM, Eric Firing notifications@github.com
|
|
did some of the pgf tests avoid getting run in 'classic' mode? |
|
Yes the pgf tests have their own slightly different image comparison for some reason. They will not run in classic mode |
|
The one Travis failure is in the docs build. I don't understand it. |
82e7bb1 to
4485888
Compare
|
The Travis failure is in the docs build, ./examples/api/custom_scale_example.py. That's a pretty complicated example, but I don't see how its failure could be related to the present PR. @mdboom, any ideas? |
|
The example fails with |
|
I think this is complete now. The last thing I added is a note in whats_new/style_changes. The change is visually so subtle that maybe it doesn't need to be mentioned here; if that's the case, the last commit can be removed. |
|
👍 after adding a test. |
ENH: add axisbelow option 'line', make it the default
|
backported to v2.x as 2ec3780 |
The present
axisbelowvalue can be only True, which puts the ticks and gridlines below patches, or False, which puts them above lines. It might make more sense to put them above patches (e.g. filled contours) and below lines. This PR adds that option, and makes it the default. See #5980 and #4243.Ideally we would be able to control ticks and gridlines separately, as requested in #4243, but this would require major refactoring. Ticklines and gridlines are drawn by
Tick.drawwhich is called byAxis.draw. Hence the order in which they are drawn relative to other plot elements is controlled byAxes.xaxis.zorderetc., not by the zorder of each gridline, for example.