-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 > > Actually, the best case IMO, would be if lines.color was deprecated and > lines.color_cycle[0] (or maybe lines.colors[0]) was used in its place. > However, this change breaks compatibility. > > -Tony -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAks6bAoACgkQ/EBMh9bUuzJ84QCeIzUXldnM1nn8DPyynPL55Jpz jAkAn1kOSchjSucIymn7CaNIGM1PrLI5 =Fp00 -----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
