-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I want to specify my own color cycle in matplotlibrc. I know I can do in the actual script: matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w']) but it renders my scripts not portable (if somebody does not have black bg in matplotlibrc as I do then he will not see the plot). (How) Can I specify my color cycle in matplotlibrc - or another portable fashion? Or at least disable it so the lines.color is used for all colors? Dominik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAksyhdYACgkQ/EBMh9bUuzJeJgCgtQSa8boMbun+vse8r6+bPhAZ PzoAoLOfH2Pnr0YFkQiR+jYo9TzB6BL5 =OtKF -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK I started hacking and added a color_cycle property to matplotlibrc. Would you be so kind to add this fix to the official version? Thanks! Dominik $ diff -w axes.py axes.py.org 135,137c135 < # DSZ take defaultColors from rcParams < # defaultColors = ['b','g','r','c','m','y','k'] < defaultColors = rcParams['axes.color_cycle'] - --- > defaultColors = ['b','g','r','c','m','y','k'] $ diff -w rcsetup.py rcsetup.py.org 442,443d441 < # DSZ add color_cycle property < 'axes.color_cycle' : [['b','g','r','c','m','y','k'], validate_stringlist], Add to custom matplotlibrc as e.g.: axes.color_cycle : w, w, w, w, w, w, w Dominik Szczerba wrote: > I want to specify my own color cycle in matplotlibrc. I know I can do in > the actual script: > > matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w']) > > but it renders my scripts not portable (if somebody does not have black > bg in matplotlibrc as I do then he will not see the plot). > > (How) Can I specify my color cycle in matplotlibrc - or another portable > fashion? Or at least disable it so the lines.color is used for all colors? > > Dominik - ------------------------------------------------------------------------------ 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkszMqcACgkQ/EBMh9bUuzJIigCgryC7tOPPkWkjjE/6/OTvLiiH OUMAoIsGCWSAC6AO3F12Rv5yQN6tMQkL =Ch5N -----END PGP SIGNATURE-----
On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote: > OK I started hacking and added a color_cycle property to matplotlibrc. > Would you be so kind to add this fix to the official version? Thanks! > Dominik > > $ diff -w axes.py axes.py.org > 135,137c135 > < # DSZ take defaultColors from rcParams > < # defaultColors = ['b','g','r','c','m','y','k'] > < defaultColors = rcParams['axes.color_cycle'] > - --- >> defaultColors = ['b','g','r','c','m','y','k'] > > > $ diff -w rcsetup.py rcsetup.py.org > 442,443d441 > < # DSZ add color_cycle property > < 'axes.color_cycle' : [['b','g','r','c','m','y','k'], > validate_stringlist], > > > > Add to custom matplotlibrc as e.g.: > > axes.color_cycle : w, w, w, w, w, w, w > 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony S Yu wrote: > > On Dec 24, 2009, at 4:21 AM, Dominik Szczerba wrote: >> OK I started hacking and added a color_cycle property to matplotlibrc. >> Would you be so kind to add this fix to the official version? Thanks! >> Dominik >> >> $ diff -w axes.py axes.py.org <http://axes.py.org> >> 135,137c135 >> < # DSZ take defaultColors from rcParams >> < # defaultColors = ['b','g','r','c','m','y','k'] >> < defaultColors = rcParams['axes.color_cycle'] >> - --- >>> defaultColors = ['b','g','r','c','m','y','k'] >> >> >> $ diff -w rcsetup.py rcsetup.py.org <http://rcsetup.py.org> >> 442,443d441 >> < # DSZ add color_cycle property >> < 'axes.color_cycle' : [['b','g','r','c','m','y','k'], >> validate_stringlist], >> >> >> >> Add to custom matplotlibrc as e.g.: >> >> axes.color_cycle : w, w, w, w, w, w, w >> > > 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 > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAks5v1QACgkQ/EBMh9bUuzL78ACdGfWMvHSI51CaH0VAWkHyL3E2 EfoAn1tdz6JBEFdlIQW78EkoqwW3hP9E =0VzO -----END PGP SIGNATURE-----
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. 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 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-----
> > 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
-----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-----
Dominik Szczerba wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OK I started hacking and added a color_cycle property to matplotlibrc. > Would you be so kind to add this fix to the official version? Thanks! > Dominik Your basic idea--that the colorcycle should be settable in rcParams--makes good sense, but the implementation needs some changes, maybe including a bit of redesign of the color cycle handling. I will look into it. A little discussion on the devel list may be required. I think we will want to completely decouple lines.color from a new lines.colorcycle, but maybe there is some good reason, other than history, for why they are coupled. Eric > > $ diff -w axes.py axes.py.org > 135,137c135 > < # DSZ take defaultColors from rcParams > < # defaultColors = ['b','g','r','c','m','y','k'] > < defaultColors = rcParams['axes.color_cycle'] > - --- >> defaultColors = ['b','g','r','c','m','y','k'] > > > $ diff -w rcsetup.py rcsetup.py.org > 442,443d441 > < # DSZ add color_cycle property > < 'axes.color_cycle' : [['b','g','r','c','m','y','k'], > validate_stringlist], > > > > Add to custom matplotlibrc as e.g.: > > axes.color_cycle : w, w, w, w, w, w, w > > > > > > > > > > Dominik Szczerba wrote: >> I want to specify my own color cycle in matplotlibrc. I know I can do in >> the actual script: >> >> matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w']) >> >> but it renders my scripts not portable (if somebody does not have black >> bg in matplotlibrc as I do then he will not see the plot). >> >> (How) Can I specify my color cycle in matplotlibrc - or another portable >> fashion? Or at least disable it so the lines.color is used for all colors? >> >> Dominik > > - > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkszMqcACgkQ/EBMh9bUuzJIigCgryC7tOPPkWkjjE/6/OTvLiiH > OUMAoIsGCWSAC6AO3F12Rv5yQN6tMQkL > =Ch5N > -----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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
One nice thing about gnuplot is the option its GUI provides to toggle between using coloured lines and using black lines with various dashed patterns. I think it would be nice in matplotlib to also be able to have a default series of dashed patterns that could automatically be cycled through. Gary R Eric Firing wrote: > Dominik Szczerba wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> OK I started hacking and added a color_cycle property to matplotlibrc. >> Would you be so kind to add this fix to the official version? Thanks! >> Dominik > > Your basic idea--that the colorcycle should be settable in > rcParams--makes good sense, but the implementation needs some changes, > maybe including a bit of redesign of the color cycle handling. I will > look into it. A little discussion on the devel list may be required. I > think we will want to completely decouple lines.color from a new > lines.colorcycle, but maybe there is some good reason, other than > history, for why they are coupled.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Firing wrote: > Dominik Szczerba wrote: > OK I started hacking and added a color_cycle property to matplotlibrc. > Would you be so kind to add this fix to the official version? Thanks! > Dominik > >> Your basic idea--that the colorcycle should be settable in >> rcParams--makes good sense, but the implementation needs some changes, >> maybe including a bit of redesign of the color cycle handling. I will >> look into it. A little discussion on the devel list may be required. I >> think we will want to completely decouple lines.color from a new >> lines.colorcycle, but maybe there is some good reason, other than >> history, for why they are coupled. Hi Eric, That's great. I would be happy if a final conclusion from the devel list could be forwarded here as well. Thanks, Dominik > >> Eric > > $ diff -w axes.py axes.py.org > 135,137c135 > < # DSZ take defaultColors from rcParams > < # defaultColors = ['b','g','r','c','m','y','k'] > < defaultColors = rcParams['axes.color_cycle'] > --- >>>> defaultColors = ['b','g','r','c','m','y','k'] > > $ diff -w rcsetup.py rcsetup.py.org > 442,443d441 > < # DSZ add color_cycle property > < 'axes.color_cycle' : [['b','g','r','c','m','y','k'], > validate_stringlist], > > > > Add to custom matplotlibrc as e.g.: > > axes.color_cycle : w, w, w, w, w, w, w > > > > > > > > > > Dominik Szczerba wrote: >>>> I want to specify my own color cycle in matplotlibrc. I know I can do in >>>> the actual script: >>>> >>>> matplotlib.axes.set_default_color_cycle(['w', 'w', 'w', 'w', 'w', 'w', 'w']) >>>> >>>> but it renders my scripts not portable (if somebody does not have black >>>> bg in matplotlibrc as I do then he will not see the plot). >>>> >>>> (How) Can I specify my color cycle in matplotlibrc - or another portable >>>> fashion? Or at least disable it so the lines.color is used for all colors? >>>> >>>> Dominik > - > ------------------------------------------------------------------------------ > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > >> - ------------------------------------------------------------------------------ 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 Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAks7PloACgkQ/EBMh9bUuzLGNgCePjtqpURRGFo4Yn6XM3991irX 7XIAoNDfZqoUh56D1wpVmXsYaIbVBQSY =bQ/o -----END PGP SIGNATURE-----
Dominik Szczerba wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Firing wrote: >> Dominik Szczerba wrote: >> OK I started hacking and added a color_cycle property to matplotlibrc. >> Would you be so kind to add this fix to the official version? Thanks! >> Dominik >> >>> Your basic idea--that the colorcycle should be settable in >>> rcParams--makes good sense, but the implementation needs some changes, >>> maybe including a bit of redesign of the color cycle handling. I will >>> look into it. A little discussion on the devel list may be required. I >>> think we will want to completely decouple lines.color from a new >>> lines.colorcycle, but maybe there is some good reason, other than >>> history, for why they are coupled. > > Hi Eric, > That's great. I would be happy if a final conclusion from the devel list > could be forwarded here as well. > Thanks, > Dominik Dominik, I added rcParams support for the color cycle to svn, but a line style cycle remains at the level of a suggestion. Eric
I'm happy for it to remain just a suggestion and not a reality. I mentioned it in case it was easy to implement alongside the color cycle but it seems it is not. Thanks for considering it anyway Eric, Gary Eric Firing wrote: > Dominik Szczerba wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Eric Firing wrote: >>> Dominik Szczerba wrote: >>> OK I started hacking and added a color_cycle property to matplotlibrc. >>> Would you be so kind to add this fix to the official version? Thanks! >>> Dominik