Norbert Nemec wrote:
> OK, I found the problem and committed a temporary fix. The real problem,
> however is rooted a bit deeper.
>
> First an explanation of the intended change:
>
> It used to be that marker colors were partly automatic, but not
> completely. I.e.
>
> plot(x,y,'-or')
>
> would set both, line color and marker color to red. However
>
> plot(x,y,color='r')
>
> would set only the line color and leave marker color to the default.
> My change was to introduce a special value 'auto' for markeredgecolor and
> markerfacecolor. This special value would cause the marker color to
> always follow
> the line color. (Which is, in 99% of the cases, what you want.) Most of
> the special logic in axes.py could therefore go away. mfc and mec would
> simply be left at 'auto' unless explicitely assigned another color. The
> handling of the special value would then happen in lines.py at time of
> plotting. (including the effect that for filled markers, the edge would
> default to black)
>
In your explanation above, it is not clear what happens in each of the 4
cases: mec auto or non-auto, and mfc auto or non-auto.
In looking at your original patch, I also wondered what is the reason
for supporting 3 different ways of specifying "_draw_nothing"? (I had
not previously noticed that there was any such thing at all, and I guess
I don't understand what it is for.)
class Line2D(Artist):
_lineStyles = {
'-' : '_draw_solid',
'--' : '_draw_dashed',
'-.' : '_draw_dash_dot',
':' : '_draw_dotted',
'steps': '_draw_steps',
'None' : '_draw_nothing',
' ' : '_draw_nothing',
'' : '_draw_nothing',
}
I was also a little uncomfortable with pushing some of the color
decision logic all the way down into the draw method, together with a
default value, although maybe there is no better way to get the desired
behavior:
if self._marker is not None:
gc = renderer.new_gc()
if (is_string_like(self._markeredgecolor) and
self._markeredgecolor == 'auto'):
if self._marker in self.filled_markers:
gc.set_foreground('k')
else:
gc.set_foreground(self._color)
else:
gc.set_foreground(self._markeredgecolor)
> The problem in r2790: I changed the default value in matplotlibrc to
> 'auto' and everything worked fine for me. I forgot that, of course,
> anybody updating from an older version, would still have the values
> 'blue' and 'black' in their matplotlibrc, which would not be overridden
> by the '.r' option that Stefan used.
This is not the first time matplotlibrc has bitten us, and it won't be
the last...
But *shouldn't* '.r' override a setting in matplotlibrc, regardless of
what that setting is? I think it should have set the mfc, or preferably
both the mfc and the mec.
>
> The (temporary) solution in r2800: I deactivated the
> rcfile-configurability of markeredgecolor and markerfacecolor. Assuming
> that hardly anybody would want to change the 'auto' behavior in their
> rcfile, this should be a good solution until we have solved the core
> problem.
>
> The core problem: The matplotlibrc file distributed with matplotlib
> contains all the default values in non-commented lines. This file is
> usually copied to the home-directory of any user, making it impossible
> to simply change any default value in later versions. It is not possible
> to find out which values in the users matplotlibrc were set on purpose
> and which were just left untouched from the distributed file.
>
> The better solution: place '#' at the beginning of every line in
> matplotlibrc.template (except for 'backend' and 'numerix' which carry
> important information) Any user who explicitely wants to change a value,
> can simply uncomment the line and set a value. Otherwise, the default
> value from matplotlib/__init__.py will remain active, even if changed in
> an update. Of course, this would only make sense, if users were informed
> and encouraged to replace their personal matplotlibrc
This seems like a good idea, and one that is consistent with the way
many other configurable systems are often handled. I think that
regardless of what else is done, this would reduce pain during updates;
it would also make it easier for the user to see what changes to the
defaults he/she has made.
>
> The ultimate solution: The file matplotlib.template should probably be
> dropped completely and be auto-created from the information in
> matplotlib/__init__.py - this would remove quite some redundancy and
> potential for inconsistencies.
Reducing redundancy is appealing, but I don't know if it would be worth
the effort of implementing your auto-generation idea--which might add
clutter and complexity to __init__.py.
Eric
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
