-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony S Yu wrote: >> >> 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"
True, in this context my solution is not ideal indeed, but the current solution is dramatic: it forces one to use black on white color scheme, else the colors are very poorly visible. Setting them in the user script ruins the portability. Most people will probably not care, therefore I believe my solution is optimal. I have to work with black background, and I am sure those like me will bother to add two extra lines to the rc file. Dominik > > The incompatibilities I spoke of would only be true if you went with my > suggestion to deprecate "lines.color". > > -T > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAks6jUsACgkQ/EBMh9bUuzLnGQCfdBclIebQBG47O1pI4I22ZvW1 bUYAoKbjsy4FTnM0sGPbTpe2rOtTjrJp =zDQ0 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ 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
