> > Tony S Yu wrote: >> On Dec 29, 2009, at 3:35 AM, Dominik Szczerba wrote: >>> Tony S Yu wrote: >>>> Hey Dominik, >>>> >>>> I'd also like to see the default color_cycle be customizeable. But, if >>>> I'm not mistaken, this approach doesn't quite do what you want (at least >>>> it doesn't on a recent version of mpl). The problem is that the color >>>> given by lines.color (rcParam) sort of overrides the first color in the >>>> specified color cycle (see >>>> ``_process_plot_var_args._clear_color_cycle`` in axes.py). >>>> >>>> It seems important for lines.color and the first color in the color >>>> cycle to match since this matching is also enforced in >>>> ``axes.set_default_color_cycle``, except in reverse (the first color in >>>> the color cycle overrides line.color). If both lines.color and >>>> axes.color_cycle (or maybe lines.color_cycle) are rcParams, there would >>>> be issues with how to match the two (e.g. which takes precedence if they >>>> differ). >>>> >>>> As I said earlier, I'd like to see this change made, but I think it may >>>> change the current behavior. Maybe a mpl developer could weigh in? >>>> >>>> -Tony >>> Hi Tony, >>> You are correct, line color overrides the first cycle color. That does >>> not appear a very happy choice to me but this way or another you can >>> still specify BOTH lines.color and the cycle in the param file to get >>> whatever you want, no? >>> >>> Dominik >> >> Yup, that should do exactly what you want. But, since it's a bit of a hack >> (you should only need to make 1 change to matplotlibrc), I doubt this patch >> would be appropriate for the main distribution. >> >> Ideally, we'd need to figure out if the matplotlibrc changes 1) only >> lines.color and make this the first color in color_cycle, 2) only >> lines.color_cycle and make the first color override lines.color, or 3) both >> lines.color and lines.color_cycle (behavior unknown if colors don't match). >> Unfortunately, I don't see an easy way to tell if rcParams have been changed >> from their default values. > > Hi Tony, > My patches (there were two!) remove the badly hardcoded definition of > defaultColors in axes.py and instead define default axes.color_cycle in > rcsetup.py (defaulting it to the already established color array > ['b','g','r','c','m','y','k']). Now, in axes.py, defaultColors are taken > from rcParams, and not a hardcoded array, so unless you modify your own > rc file, you will get the old behavior. It is if and only if you define > your color_cycle in your own rc file that will do anything new. I do not > see how this introduces any incompatibilities. > Dominik
Sorry for the confusion. I wasn't saying your patches introduce incompatibilities, but I did say that their behavior is not ideal. For example, your matplotlibrc requires *both* "lines.color_cycle : w, w, w, w, w, w" (actually I think you only need one "w,") *and* "lines.color : w". Ideally (at least IMO), I should only need to set the color cycle, and it was surprising to me (surprises = bad) that I'd have to also set "lines.color" The incompatibilities I spoke of would only be true if you went with my suggestion to deprecate "lines.color". -T
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
