Re: [Matplotlib-users] define color cycle in matplotlibrc

[Dominik S. <do...@it...>]

-----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-----