2010/8/20 Michael Droettboom <md...@stsci.edu>: >> Yeah, it's my issue, but I'm not happy with fixing it. Currently, >> matplotlib forces the xticks (i.e., the theta ticks) to be at sensible >> values via .set_xticks() and .set_xlabels() (projections/polar.py). >> >> I'm coding a matplotlib extension package which has to clear the axes >> often, but restoring the major locators, the title and stuff after >> clearing. It was agnostic to the specialities of polar axes so far. > > Why and how are you restoring the major locator? It seems like that's the > issue. I don't think preventing the theta locator from being changed is > something we want to do. Polar plots (by default) just set fixed theta > ticks at multiples of pi/4.
My package provides support for Layers in matplotlib. And the layers' data can be changed, making a complete redraw of the axes a solution much easier to implement than dealing with the fuzzy API stuff directly. I don't need high-performance. When putting axes.clear(), the locator is being reset. In cartesian coords, it happens that I want a MaxNLocator(nbins=3) or similiar from time to time, and this must be restored then. For cartesian axes, if the user does not specify another locator, I'm setting the AutoLocator(), what is the same what the (cartesian) axes does. Dealing with the case "no locator set" (by "using matplotlib default fallback") is neither nice nor straightforward. (It has to do with complicating the calling conventions. I would have to treat the case 'ignore [x|y]locator' specially.) It would maybe be a good solution to provide some abstract Axes.get_default_locators(), being public. Each SomeClass(Axes) can define what they understand under "default locator". >> I would rather suggest to insert a new Locator class being aware of >> radians. It would suffice to return tick positions dividing 2 pi into >> an integer number of bins. It's not necessary to cover all the >> peculiarities of the old historic division system into 360 parts. > > Perhaps using FixedLocator, rather than explicitly setting the ticks using > set_xticks (as polar plots currently do) would be better. However, the > locator could still be changed, not really addressing your problem. Seems that you misunderstood my problem, if I'm not misunderstanding you :-) I have no problem with a "mutable" locator. (But the user has normally no access to the axes, only the Stack class changes the axes.) But right, I wanted to derive it from the Locator class framework, just specialising the location. > For convenience, however, we could add a locator that given n, divides 2pi > into n parts. Yes, and Ben's idea is quite nice, to make this accessible also to rectangular plots. This implies some simple thoughts on the view lims to take them into account when issuing the tick locations. >> Accompanying would be formatters in radians and degrees with >> adjustable precision (no autodetect necessary). > > Sure. Adding a radian formatter makes sense. If we go into details let's switch to -devel maybe? Friedrich ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
