On Jan 4, 2012, at 20:52, Benjamin Root <ben.r...@ou.edu> wrote: > Hello all, > > So, I am getting to the point where I need to implement a color cycling > mechanism throughout pyplot. So, before I get too deep in implementing it, I > have some thoughts that I need feedback on. > > 1) Not all plotting functions use color cycling right now. Currently, only > plot() and any function that calls plot in its process (such as errorbar()). > Glaring omissions are bar() and scatter(), and pie() could also benefit from > having a uniform cycling mechanism. So, the issue going forward is, do we > want to enable common cycling for all the pyplot/axes plotting functions > which would require updating the test images and break backwards > compatibility (in a sense), or do we want to have a per-function default > rcparams that would contain one-element cycles that would effectively > maintain current drawing results? > > 2) I also have the need to implement line-style cycling for b&w publications. > Of course if I implement that, then why not hatch-cycling? marker-cycling? I > have seen use-cases for all of these, and I am considering how to have a > generalized framework for this. So my question is, what attributes would we > like to see cycle-able? Here is a short list and some usecases I have come up > with. Please extend this with ideas of your own. > > color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem() > linestyle - plot(), errorbar(), stem() > hatch - bar(), hist(), pie() > marker - plot(), errorbar(), scatter(), stem() > > linewidth? facecolor/edgecolor? joinstyle? > > 3) rcparam names. I was thinking about how to name these cycles in the > matplotlibrc file. Possibly: > > cycle.colors > cycle.linestyles > cycle.hatches > cycle.markers > > And these would represent the global default, meanwhile, function-specific > cycles could be given by: > > cycle.colors.pie > cycle.colors.bar > cycle.linestyles.plot > cycle.linestyles.errorbar > > I was thinking that in code, one would access the full name attribute for the > function, and I would extend the __get__ function to intelligently fall back > to the global default if the full-name attribute is not specified. However, > would there be confusion in a situation such as a person who wanted to use > barh() but only had specified cycle.colors.bar? > > 4) Ultimately, my goal is to be able to create some typical profiles that > have useful cycle specs, and possibly make some available as convenience > functions, such as a b&w mode. Such a mode would set the default colormap to > a grayscale-friendly colorscale, and use line style, hatch and marker cycles > instead of a full color cycle. > > Thoughts? Comments?
My first thought is that maybe we need an object to collect and abstract all of these style attributes, and then cycle through a sequence of those. In the future we could move the matplotlib API to use such an object instead of the billion parameters that are individually passed now. Just 0.02 to distract me from the dissertation. Ryan ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
