matplotlib-users Mailing List for matplotlib

>>>>> "Uwe" == Uwe Hoffmann <qu...@ti...> writes:
 Uwe> Hi, i am using the simple_plot.py example with the Agg or
 Uwe> WXAgg backends. If i insert the following line:
 Uwe> rcParams["figure.facecolor"] = "r" the background is red when
 Uwe> using the WXAgg driver but with the Agg backend the
 Uwe> background of the png image is still white.
 Uwe> Any hints ? (matplotlib 0.64, linux)
help(savefig)
The default figure facecolor is passed as a kwarg in savefig. The
idea is that you often want a different background color for the
figure in a GUI (eg gray) and in hardcopy (eg white)
 savefig('myfile', facecolor='r') 
should work.
JDH

Hi,
i am using the simple_plot.py example with the Agg or WXAgg backends.
If i insert the following line:
rcParams["figure.facecolor"] = "r"
the background is red when using the WXAgg driver but with the Agg 
backend the background of the png image is still white.
Any hints ?
(matplotlib 0.64, linux)
greetings
	Uwe

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 Perry> In thinking about the ioff(), ion() approach it occurs to
 Perry> me that it may not be quite so simple for scripts. I think
 Perry> a common desire is for a script or function to turn off
 Perry> interactive mode if it is on, but at the end, restore the
 Perry> previous interactive state. In this case a push/pop
 Perry> approach to interactive mode may be more appropriate rather
 Perry> than stop/start. In particular, if interactive mode
 Perry> happended to be off, you wouldn't want to turn it on at the
 Perry> end of the script.
BTW, Eric emailed me off list. It appears that running his script in
interactive mode was the root cause of his performance problems.
In regards to running scripts from the python shell, I think the least
invasive approach is to write a run function that stores the
interactive state, calls ioff, runs the script with execfile, then
calls ion (precisely what ipython does). In fact, perhaps we should
add a run function to the pylab interface which does just this.
Fernando could simply override this function if he wants to do some
additional ipython magic. But this would wrap the logic for those who
want to run scripts from the other python shell. Of course it would
only work for non-image backends and Tk, or GUI backends associated
with a GUI shell like pycrust.
I'm less worried about people inadvertently running scripts from the
command shell with interactive set to True, because interactive
defaults to False in rc and thus the person would have had to
intentionally change it, at least at some point in dark history.
Hence they are probably aware of it. Singing the praises of ipython
yet again, I leave the default in my rc to False, and run ipython when
I want to work interactively, letting ipython turn interaction on for
me. Thus I can run python somescript.py from the command shell assured
that it is off, and still use matplotlib interactively w/o having to
tweak the setting. 
But if there is some concern for users who would like to leave
interactive on in rc (eg they like to use the standard python shell or
some other shell) and still be able to get the efficiency when running
scripts from the command shell, it might be possible to inspect
whether we are in a running in a python shell, and plug this
additional information into draw_if_interactive. Something like
def draw_if_interactive():
 if running_in_python_shell() and matplotlib.is_interactive():
 canvas.draw()
Anyone know how to determine whether you are running code in a python
shell versus running a script, eg from a command shell?
It occurs to me that "interactive" is not really the best name for
this matplotlib state. Really we want something that conveys
"draw_after_every_plot_command". When I named it, I was assuming that
when working interactively you would want to update with every plot
command, but have learned that this is not always the case. Do you
think it's worth coming up with new names (isdraw(),
draw_always(True/False), etc, while preserving the old names for a
while with deprecation)? Because that's what we're really doing,
controlling the drawing.
JDH

In thinking about the ioff(), ion() approach it occurs to me that
it may not be quite so simple for scripts. I think a common 
desire is for a script or function to turn off interactive mode
if it is on, but at the end, restore the previous interactive 
state. In this case a push/pop approach to interactive mode may
be more appropriate rather than stop/start. In particular, if 
interactive mode happended to be off, you wouldn't want to turn
it on at the end of the script.
Perry