matplotlib-users Mailing List for matplotlib (Page 6)

Hi,
is there a solution for using matplotlib within pyside like it is
possible with pyqt4?
Greetz
Marc

Thanks. With this new script, I get only one failure:
xpdf_False
This is on RHEL5 x86_64:
gs 8.15.2
gv 3.6.8
pdftops 3.00
Cheers,
Mike
On 11/16/2010 06:54 AM, Jae-Joon Lee wrote:
> On Mon, Nov 15, 2010 at 11:29 PM, Michael Droettboom<md...@st...> wrote:
> 
>> How do I verify if the bbox is correct? Displaying them with gs, some of them have the plot centered on what looks to be a letter-sized page, and others are at the bottom, but none of them seem to be cropped. I'm happy to give a full detailed report, just not sure what I'm looking for in terms of right/wrong ;)
>>
>> Thanks,
>> Mike
>>
>> 
> Michael,
>
> Here is a slightly modified example.
>
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> plt.plot([0, 1, 1, 0], [0, 0, 1, 1], "ro", ms=10, transform=fig.transFigure,
> clip_on=False)
>
> for distiller in ["False", "xpdf", "ghostscript"]:
> for usetex in ["True", "False"]:
> plt.rcParams["ps.usedistiller"]=distiller
> plt.rcParams["text.usetex"]=usetex
>
> plt.savefig("test_bbox_%s_%s.eps" % (distiller, usetex))
>
> With this, you should see four red circles (a quadrant of a circle) at
> the four corner of page boundaries.
> I don't think "gs" is a right tool to test if the bbox is correct. My
> experience is that it often ignores the bbox. On linux, you may use
> "gv", "evince", or "okular".
>
> Regards,
>
> JJ
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

All,
I have experience getting MPL working with wx backend with py2exe, and I
have sucessfully packaged and delivered py2exe executables (email me if you
would like a copy of the setup.py file that worked for me).
I have decided to switch my main development from wx to GTK since Glade is
so much easier to use (and get support for) than wxGlade.
Now my main problem is getting GTK to play nicely with MPL and py2exe. So
far Ive had no luck. The program runs perfectly when not packaged into an
executable FWIW. I copied my setup.py file at the end of the email.
 Perhaps someone has an idea. I import MPL with
import matplotlib
matplotlib.use('GTKAgg')
which immediately spits out an error:
(GTKAPP.exe:4188): GdkPixbuf-WARNING **: Cannot open pixbuf loader module
file 'gtk-2.0\gdk-pixbuf.loaders': No such file or directory
I tried to follow the recommendations of
http://www.py2exe.org/index.cgi/Py2exeAndPyGTK with moving the etc, share,
lib folders to the dist folder and I even in desperation added the etc,
share and lib folders to the path prior to importing MPL. No dice.
Any thoughts?
My setup.py that doesn't work with GTKAgg:
from distutils.core import setup
import py2exe
excludes = ['_tkagg', '_wxagg','_wx','_cocoaagg','_fltkagg','bsddb',
'curses', 'pywin.debugger',
 'pywin.debugger.dbgcon', 'pywin.dialogs', 'tcl',
 'Tkconstants', 'Tkinter', 'pydoc', 'doctest', 'test', 'sqlite3',
 'projections','Tcl','PyQT4','qt','backend_qt','backend_qt4','backend_qt4agg',
 'backend_qtagg','backend_cairo','backend_cocoaagg','wx','scipy.sparse'
 ]
dll_excludes = ['QTGui4.dll','QtCore4.dll','tk85.dll','tcl85.dll']
data_files=['CurveFit.ui',]
packages = ['pygtk','matplotlib','encodings','gtk']
includes = ['cairo','pangocairo','atk','gobject','pango']
import matplotlib as mpl
data_files += mpl.get_py2exe_datafiles()
setup(
 name = 'FitTool',
 description = 'CurveFittingTool',
 version = '0.1',
 console = [
 {
 'script': 'GTKAPP.py',
 }
 ],
 options = {"py2exe": {"compressed": 2,
 "optimize": 2,
 "excludes": excludes,
 "packages": packages,
 "includes": includes,
 "dll_excludes": dll_excludes,
 # using 2 to reduce number of files in dist folder
 # using 1 is not recommended as it often does not
work
 "bundle_files": 2,
 "dist_dir": 'dist',
 "xref": False,
 "skip_archive": False,
 "ascii": False,
 "custom_boot_script": '',
 }
 },
 # using zipfile to reduce number of files in dist
 zipfile = r'libFiles\library.zip',
 data_files=data_files
)
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

You may use annotate.
annotate("Test", xy=(0.5, 0.3), xycoords=("axes fraction", "data"), ha="center")
This requires v1.0 of matplotlib.
http://matplotlib.sourceforge.net/users/annotations_guide.html#using-complex-coordinate-with-annotation
Regards,
-JJ

On Mon, Nov 15, 2010 at 1:40 PM, <dav...@ub...> wrote:
> Hi
>
>
>
> I’d like to place a piece of text that shows the start of some data so I
> want data coords in the x direction and axis coords in the y – e.g. float
> with a particular x value and center in the screen on the y.
>
>
>
> Do I need to implement a new object or can I mix transforms in this manner?
>
>
>
> Many thx
>
>
>
> David
>
>
I believe "Blended" transformations is what you are looking for:
http://matplotlib.sourceforge.net/users/transforms_tutorial.html#blended-transformations
Haven't tried it myself, but the description seems right.
Ben Root

Since you are using OpenSuse, (and If you are brave enough) you can
add my REPO and use the latest version of matplolib:
http://download.opensuse.org/repositories/home:/ocefpaf/openSUSE_11.3/
I compile the svn version every week there.
Filipe.
On Mon, Nov 15, 2010 at 13:45, Michael Droettboom <md...@st...> wrote:
> Since their package is crashing, I would report this bug against OpenSUSE's python-matplotlib package.
>
> If that doesn't get you any response, it would be helpful to get a better idea of where it is failing. Can you provide a gdb backtrace?
>
> Mike
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I think the pretty-fying done in the Colorbar class will make this 
harder; at least, twiny on an existing colorbar doesn't work 
(overwrites original ticks); having two colorbars works fine but 
wastes space; and adding a spine had surprising side-effects (changed 
the color range!).
I would guess that you want a custom Colorbar class, with a different 
offset for a second set of ticks.
note that in colorbar.py, there's some code specific to CountourSets.
&C
On Nov 15, 2010, at 15 Nov, 8:22 AM, Daniel Welling wrote:
> Greetings.
>
> I am making some contour plots and in my field for this particular 
> value, there are two widely used units. As such, it is very useful 
> to have both units listed on the colorbar. To clarify: the 
> colorbar's normal ticks would be facing to the right and labeled 
> with Unit Type 1, which was the units that the data were in when 
> they were plotted. Unit Type 2 is simply a factor of X different 
> than unit type two. It would be nice if I could add a second set of 
> ticks to the color bar using a different locator and have them face 
> left. Is this possible? Is there another way to display two values 
> for each tick such that the colorbar shows both units?
>
> Thanks.
> -dw
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Chloe Lewis
Ecosystem Sciences, Policy and Management, UC Berkeley
137 Mulford Hall
Berkeley, CA 94720-3114
http://nature.berkeley.edu/~chlewis

Visit our website at http://www.ubs.com 
This message contains confidential information and is intended only 
for the individual named. If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail. Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system. 
E-mails are not encrypted and cannot be guaranteed to be secure or 
error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender 
therefore does not accept liability for any errors or omissions in the 
contents of this message which arise as a result of e-mail transmission. 
If verification is required please request a hard-copy version. This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities 
or related financial instruments. 
UBS Limited is a company limited by shares incorporated in the United 
Kingdom registered in England and Wales with number 2035362. 
Registered office: 1 Finsbury Avenue, London EC2M 2PP. UBS Limited 
is authorised and regulated by the Financial Services Authority. 
UBS AG is a public company incorporated with limited liability in 
Switzerland domiciled in the Canton of Basel-City and the Canton of 
Zurich respectively registered at the Commercial Registry offices in 
those Cantons with Identification No: CH-270.3.004.646-4 and having 
respective head offices at Aeschenvorstadt 1, 4051 Basel and 
Bahnhofstrasse 45, 8001 Zurich, Switzerland. Registered in the 
United Kingdom as a foreign company with No: FC021146 and having a 
UK Establishment registered at Companies House, Cardiff, with No: 
BR 004507. The principal office of UK Establishment: 1 Finsbury Avenue, 
London EC2M 2PP. In the United Kingdom, UBS AG is authorised and 
regulated by the Financial Services Authority.
UBS reserves the right to retain all messages. Messages are protected 
and accessed only in legally justified cases. 

Since their package is crashing, I would report this bug against OpenSUSE's python-matplotlib package.
If that doesn't get you any response, it would be helpful to get a better idea of where it is failing. Can you provide a gdb backtrace?
Mike

Hi,
Since upgrading to SUSE 11.3 matplotlib simply craches
(segfault on dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2);
> python -V
Python 2.6.5
> uname -a
Linux mcp20 2.6.34.7-0.5-default #1 SMP 2010年10月25日 08:40:12 +0200 i686 i686 i386 GNU/Linux
I did a 1-Click Installation from http://software.opensuse.org.
http://software.opensuse.org/search/download?base=openSUSE%3A11.3&file=devel%3A%2Flanguages%3A%2Fpython%2FopenSUSE_11.3%2Fi586%2Fpython-matplotlib-1.0.0-2.9.i586.rpm&query=python-matplotlib
So I have python-matplotlib-1.0.0-2.9.i586.rpm
When I do:
python -v -c "import matplotlib.figure"
...
import matplotlib.docstring # precompiled from /usr/lib/python2.6/site-packages/matplotlib/docstring.pyc
# /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc matches /usr/lib/python2.6/site-packages/matplotlib/transforms.py
import matplotlib.transforms # precompiled from /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc
dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2);
Speicherzugriffsfehler
(means "Segfault")
The same is when I do:
python -v -c "from pylab import *"
mport matplotlib.docstring # precompiled from /usr/lib/python2.6/site-packages/matplotlib/docstring.pyc
# /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc matches /usr/lib/python2.6/site-packages/matplotlib/transforms.py
import matplotlib.transforms # precompiled from /usr/lib/python2.6/site-packages/matplotlib/transforms.pyc
dlopen("/usr/lib/python2.6/site-packages/matplotlib/_path.so", 2);
Speicherzugriffsfehler
I googled around.
Some Chaco users seems to have similar problems.
But for now I have no idea what to do next.
Please, somebody be so kind and give me some hint.
Have a nice day.
-- 
Kurt Müller, mu...@pr...

Greetings.
I am making some contour plots and in my field for this particular value,
there are two widely used units. As such, it is very useful to have both
units listed on the colorbar. To clarify: the colorbar's normal ticks would
be facing to the right and labeled with Unit Type 1, which was the units
that the data were in when they were plotted. Unit Type 2 is simply a
factor of X different than unit type two. It would be nice if I could add a
second set of ticks to the color bar using a different locator and have them
face left. Is this possible? Is there another way to display two values for
each tick such that the colorbar shows both units?
Thanks.
-dw

On Friday 12 Nov 2010 15:20:43 Ryan May wrote:
> On Fri, Nov 12, 2010 at 8:40 AM, Benjamin Root <ben...@ou...> wrote:
> > On Fri, Nov 12, 2010 at 5:11 AM, Guy Griffiths
> > <guy...@re...>
> > 
> > wrote:
> >> Hi,
> >> 
> >> I've been using matplotlib for a while for plotting scientific data, and
> >> recently upgraded from version 0.99.1.1 to 1.0.0. Primarily I use
> >> pcolor to
> >> produce plots of concentration in 2D space. I use reasonably fine
> >> meshes, and
> >> in v0.99.1.1 the output looked great.
> >> 
> >> In v1.0.0, all of my plots (using the same code) have faint gridlines
> >> visible.
> >> Since the mesh I am using is quite fine, this makes the plots look
> >> terrible
> >> (i.e. more gridlines than actual data). This seems to be controlled by
> >> the
> >> "edgecolors" keyword, but even when set to 'none' they are still there.
> >> Is
> >> there any way to remove them completely without reverting back to
> >> 0.99.1.1 (which I'd prefer not to do, since some of the API changes are
> >> really useful
> >> for creating very polished graphs suitable for publication)?
> >> 
> >> imshow seems to have closer results to what I want (i.e. no gridlines),
> >> but
> >> with imshow, the axes denote the pixel position, and there is no option
> >> to display on polar axes (which is essential).
> >> 
> >> Any help would be much appreciated.
> >> 
> >> Regards,
> >> 
> >> Guy Griffiths
> > 
> > Guy, I have noticed something similar a few months ago with pcolor, but I
> > am not certain if it is the same problem as yours. First, which backend
> > are you using? Second, are you seeing the grid lines in both the figure
> > window and the saved output? Also, what format are you saving your
> > output to? Lastly, which pcolor function are you using (pcolor(),
> > pcolormesh(), pcolorfast())?
> > 
> > If you could include a screenshot or the saved file, I could see if it is
> > similar to my problem.
> 
> Yeah, I had noticed a problem with pcolor too. You can see the problem
> I've been seeing here:
> 
> http://matplotlib.sourceforge.net/examples/pylab_examples/pcolor_demo.html
> 
> Calling pcolor with antialiased=False removes the lines, but that's
> just a workaround, not a solution. I'm not really sure where to start
> to track this down, so if anyone has a suggestion, I'm all ears.
> 
> Ryan
Hi,
Thanks for the help. The problem I'm seeing is as Ryan describes (same effect 
as in the screenshot, but let me know if you still want me to provide an 
example), and appears in both the figure window and saved output (at least png 
and pdf). The backend I am using is Qt/Agg. I was using pcolor(), but it 
appears that pcolormesh() doesn't (always) have this problem. Setting 
antialiased=False removes some of the problems. In summary:
pcolor(), antialiased=True - lines on screen, png, pdf
pcolor(), antialiased=False - lines on pdf, fine on png/screen
pcolormesh() - lines on pdf, fine on png/screen
Regards,
Guy

Hello,
I would like to plot the polarization state of a two-dimensional vector
field (linear, circular or generally elliptic), similarly to that seen on
this ZEMAX plot:
http://www.zemax.com/UserFiles/Image/UI/pol_pupil.gif
It looks like some kind of enhanced quiver plot: a small line with arrows at
both ends points out the local direction of linear polarization, while a
directed ellipse with a given orientation of its axes depicts local
elliptical polarization state (which becomes a circle for circular
polarization).
I am a novice matplotlib user, please give me some advice on how to start
with implementing such a plot (what to read, API examples to look at etc.)
Thanks,
Kornel JAHN

On Sat, Nov 13, 2010 at 7:58 PM, Michiel de Hoon <mjl...@ya...>wrote:
> Thanks for your reply.
>
> Regarding your first question, how exactly does it disrupt your workflow?
> Is it because the drawing takes too much time? Or because the focus switches
> from the terminal window to the figure window? Or because the figure takes
> up screen space?
>
>
It is partly because the focus switches from the terminal window to the
figure window (at least, at fiirst it does), but mostly because there isn't
enough screen real estate for both to co-exist. Therefore, I would be
alt-tabbing a lot if I am in interactive mode.
Anyway, I mostly work from the perspective of running scripts and larger
programs to generate publication quality figures and to perform data
analyses. My focus is not on messing around with my figures. The only time
I am doing that is when I am developing and testing a new script or feature,
in which case I might go into interactive mode to figure out what settings
and such make my figures look nice, or maybe not.
It is nice to have the option to suit my needs. More often than not, I am
in non-interactive mode. I see no reason to remove this feature as it puts
matplotlib ahead of other systems like Matlab. Choice is a good thing...
Ben Root

Thanks for your reply.
Regarding your first question, how exactly does it disrupt your workflow? Is it because the drawing 
takes too much time? Or because the focus switches from the terminal 
window to the figure window? Or because the figure takes up screen 
space?
Regarding the OP, my understanding is that the original issue is that with interactive=False, the MacOSX backend pops up a window while the other backends do not. It doesn't make a difference in running time, but anyway the different backends should behave the same way, so something needs to be done here.
--Michiel.
--- On Sat, 11/13/10, Benjamin Root <ben...@ou...> wrote:
I would like to cast a vote of support for the "interactive=False" setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow.
...
On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here.
 

Thanks for your reply.
--- On Sat, 11/13/10, Eric Firing <ef...@ha...> wrote:
> In the gtk backend, draw_idle calls gobject.idle_add 
> 
> Thus, "idle" means the gui event loop has no higher
> priority events. Is 
> this condition reached only at the end of the script?
With Python, there is only one thread (running both Python and the GUI). So the GUI event loop won't start until the end of the script, so there is no inadvertent redrawing regardless of interactive being True or False.
With ipython, I am not sure if they are using one thread, or one thread for Python and one thread for the GUI. But in practice, in ipython I also don't find any evidence of inadvertent redrawing. For example, this script:
import matplotlib
matplotlib.use("gtkagg")
import matplotlib.pyplot as plt
import numpy
x = numpy.random.random(400000)
y = x + numpy.random.random(400000)
plt.figure()
plt.hexbin(x, y, gridsize=300)
for i in range(1000):
 plt.xlabel('a label')
plt.show()
both with python and ipython take an equal amount of time regardless of interactive being True or False. If there were any redrawing after each call to plt.xlabel, this script would take forever.
> Reminder: the interactive setting controls
> draw_if_interactive, which is 
> what we are talking about here, but also whether or not
> show() blocks. 
> So we may not need draw_if_interactive, but unless we can
> dispense with 
> show entirely, we will still need an interactive setting.
If matplotlib were always interactive, then I don't see a good reason for non-blocking show().
> Returning to the issue raised by the OP, however, the
> question is 
> whether the present MacOSX behavior (windows pop up) or the
> non-MacOSX 
> behavior (they don't in non-interactive mode until/unless
> show() is 
> called) is what we really want. It seems to me that
> we should preserve 
> some way of getting this second behavior.
I agree. For example, if a user wants to make a figure for the sole purpose of creating a PNG file, there should be a way to do this without the figure popping up as a window.
--Michiel.
 

On Sat, Nov 13, 2010 at 12:06 PM, Eric Firing <ef...@ha...> wrote:
> On 11/13/2010 06:16 AM, Michiel de Hoon wrote:
> > --- On Sat, 11/13/10, John Hunter<jd...@gm...> wrote:
> >> Ie if we have a script like
> >>
> >> # some plotting commands
> >> ...
> >>
> >> # some expensive non GUI computation
> >> ...
> >>
> >> # some update to plot above
> >> ...
> >>
> >> Would we not run the risk that the GUI is idle in the non
> >> GUI computation and therefore trigger a draw in it's thread,
> >> and then do redraws again after the update code?
> >
> > In the MacOSX backend, everything is single-threaded, so this won't
> occur.
> >
> > I am not sufficiently familiar with the non-MacOSX backends to give a
> detailed answer, but with multiple threads the "idle" refers to the Python
> thread being idle rather than the GUI thread being idle. In other words,
> when there are no more Python commands left to be handled, the GUI thread is
> notified that it should start redrawing.
> >
>
> In the gtk backend, draw_idle calls gobject.idle_add
>
> http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject--idle-add
>
> Thus, "idle" means the gui event loop has no higher priority events. Is
> this condition reached only at the end of the script?
>
>
> >> Are you proposing that we can get rid of the interactive setting
> >> entirely, always call draw on pyplot commands, and let the
> >> idle handler save us from doing repeated draws?
>
> Reminder: the interactive setting controls draw_if_interactive, which is
> what we are talking about here, but also whether or not show() blocks.
> So we may not need draw_if_interactive, but unless we can dispense with
> show entirely, we will still need an interactive setting.
>
> Returning to the issue raised by the OP, however, the question is
> whether the present MacOSX behavior (windows pop up) or the non-MacOSX
> behavior (they don't in non-interactive mode until/unless show() is
> called) is what we really want. It seems to me that we should preserve
> some way of getting this second behavior.
>
> Eric
>
> >
> > Yes (I assume you mean to always call draw_idle on pyplot commands). If
> there are then still cases where we do get repeated draws, then that is a
> bug.
> >
> > Best,
> > --Michiel.
> >
>
>
I would like to cast a vote of support for the "interactive=False" setting.
I often do work on my netbook, and having a figure window pop up while I am
testing out some commands disrupts my workflow. When I want to see all my
figures, I will call show() when I am good and ready. And just as I often
do work on my netbook, I also do plenty of work on my workstation which
sports a large screen. In many cases on that machine, I would like to see
my figures while I am working on them, and having an easy option to turn
that on and off is valuable to me.
interactive : False was one of several reasons why I switched from Matlab to
matplotlib.
On the issue about the OP, I am a little bit confused as to what the exact
issue is at hand. Is it that a figure window pops up in macosx backend
regardless of the interactive setting? Or is it that non-macosx backends
are not behaving the same way on a mac as they do on other systems? Is the
issue that the plot window is blank on the macosx backend until the script
finishes? I guess I am a little confused here.
Ben Root

On 11/13/2010 06:16 AM, Michiel de Hoon wrote:
> --- On Sat, 11/13/10, John Hunter<jd...@gm...> wrote:
>> Ie if we have a script like
>>
>> # some plotting commands
>> ...
>>
>> # some expensive non GUI computation
>> ...
>>
>> # some update to plot above
>> ...
>>
>> Would we not run the risk that the GUI is idle in the non
>> GUI computation and therefore trigger a draw in it's thread,
>> and then do redraws again after the update code?
>
> In the MacOSX backend, everything is single-threaded, so this won't occur.
>
> I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing.
>
In the gtk backend, draw_idle calls gobject.idle_add 
http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject--idle-add
Thus, "idle" means the gui event loop has no higher priority events. Is 
this condition reached only at the end of the script?
>> Are you proposing that we can get rid of the interactive setting
>> entirely, always call draw on pyplot commands, and let the
>> idle handler save us from doing repeated draws?
Reminder: the interactive setting controls draw_if_interactive, which is 
what we are talking about here, but also whether or not show() blocks. 
So we may not need draw_if_interactive, but unless we can dispense with 
show entirely, we will still need an interactive setting.
Returning to the issue raised by the OP, however, the question is 
whether the present MacOSX behavior (windows pop up) or the non-MacOSX 
behavior (they don't in non-interactive mode until/unless show() is 
called) is what we really want. It seems to me that we should preserve 
some way of getting this second behavior.
Eric
>
> Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug.
>
> Best,
> --Michiel.
>

--- On Sat, 11/13/10, John Hunter <jd...@gm...> wrote:
> Ie if we have a script like
> 
>  # some plotting commands
>  ...
> 
>  # some expensive non GUI computation
>  ...
> 
>  # some update to plot above
>  ...
> 
> Would we not run the risk that the GUI is idle in the non
> GUI computation and therefore trigger a draw in it's thread,
> and then do redraws again after the update code?
In the MacOSX backend, everything is single-threaded, so this won't occur.
I am not sufficiently familiar with the non-MacOSX backends to give a detailed answer, but with multiple threads the "idle" refers to the Python thread being idle rather than the GUI thread being idle. In other words, when there are no more Python commands left to be handled, the GUI thread is notified that it should start redrawing.
> Are you proposing that we can get rid of the interactive setting
> entirely, always call draw on pyplot commands, and let the
> idle handler save us from doing repeated draws?
Yes (I assume you mean to always call draw_idle on pyplot commands). If there are then still cases where we do get repeated draws, then that is a bug.
Best,
--Michiel.
 

On Sat, Nov 13, 2010 at 9:23 AM, Michiel de Hoon <mjl...@ya...> wrote:
> Thanks for your reply.
> But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False.
I see. I wasn't appreciating your point and had neglected to consider
the idle drawing handling. Are we sure this will save us. Ie if we
have a scirpt like
 # some plotting commands
 ...
 # some expensive non GUI computation
 ...
 # some update to plot above
 ...
Would we not run the risk that the GUI is idle in the non GUI
computation and therefore trigger a draw in it's thread, and then do
redraws again after the update code? I did run some tests and
confirmed what you said, that with the idle handling the repeat calls
to pyplot commands did not generate extra calls (except in qtagg in
which I suspect the idle handling has not been implemented.
Are you proposing that we can get rid of the interactive setting
entirely, always call draw on pyplot commands, and let the idle
handler save us from doing repeated draws?

Thanks for your reply.
But nowadays drawing is done through draw_idle, so we don't trigger additional drawing even if interactive is True. In your example, if run as a script, there is no drawing until a call to show() is made, regardless of whether interactive is True or False.
Best,
--Michiel.
--- On Sat, 11/13/10, John Hunter <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: Re: [Matplotlib-users] Mac OSX backend
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "mdekauwe" <mde...@gm...>, mat...@li...
> Date: Saturday, November 13, 2010, 9:22 AM
> On Sat, Nov 13, 2010 at 7:46 AM,
> Michiel de Hoon <mjl...@ya...>
> wrote:
> > OK, thanks. With your example, I see a difference
> between the Mac OS X backend and the TKAgg/GtkAgg backend
> but only if interactive is False in matplotlibrc. If
> interactive is True, both the Mac OS X backend and the TkAgg
> backend open windows. Is this really the desired behavior?
> It seems counterintuitive that such a global parameter can
> determine whether a figure is opened or not.
> >
> > While we're on the topic, is this interactive
> parameter still needed in matplotlib? In my understanding,
> in older versions of matplotlib, interactive=False could
> significantly speed up some plots. But are there still any
> such cases with the current organization of the drawing code
> in matplotlib?
> 
> 
> Yes, this is the desired behavior. The interactive :
> True parameter
> is useful when working interactively from the shell, when
> want to do
> 
>  plt.figure()
>  plt.plot([1,2,3])
>  plt.xlabel('a label')
> 
> and have the figure show up on the figure call and update
> on the plot
> and xlabel call. This is most definitely not what you
> want to do in a
> script, because you don't want to pay for the draw until
> the end (when
> a call to show is made). This is discussed at
> 
>  http://matplotlib.sourceforge.net/users/shell.html
> 
> JDH
> 
 

On Sat, Nov 13, 2010 at 7:46 AM, Michiel de Hoon <mjl...@ya...> wrote:
> OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not.
>
> While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib?
Yes, this is the desired behavior. The interactive : True parameter
is useful when working interactively from the shell, when want to do
 plt.figure()
 plt.plot([1,2,3])
 plt.xlabel('a label')
and have the figure show up on the figure call and update on the plot
and xlabel call. This is most definitely not what you want to do in a
script, because you don't want to pay for the draw until the end (when
a call to show is made). This is discussed at
 http://matplotlib.sourceforge.net/users/shell.html
JDH

OK, thanks. With your example, I see a difference between the Mac OS X backend and the TKAgg/GtkAgg backend but only if interactive is False in matplotlibrc. If interactive is True, both the Mac OS X backend and the TkAgg backend open windows. Is this really the desired behavior? It seems counterintuitive that such a global parameter can determine whether a figure is opened or not.
While we're on the topic, is this interactive parameter still needed in matplotlib? In my understanding, in older versions of matplotlib, interactive=False could significantly speed up some plots. But are there still any such cases with the current organization of the drawing code in matplotlib?
Thanks,
--Michiel.
--- On Fri, 11/12/10, John Hunter <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: Re: [Matplotlib-users] Mac OSX backend
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: "mdekauwe" <mde...@gm...>, mat...@li...
> Date: Friday, November 12, 2010, 9:06 AM
> On Thu, Nov 11, 2010 at 7:32 PM,
> Michiel de Hoon <mjl...@ya...>
> wrote:
> > For this example, I am finding the exact same behavior
> with the Mac OS X backend as with the gtkcairo and gtkagg
> backends (on Mac OS X and Cygwin). If this is a bug, then
> which backend can we use as an example of the correct
> behavior for this code?
> 
> On a quick test, the following script
> 
>  import matplotlib.pyplot as plt
>  for i in range(4):
>    fig = plt.figure()
> 
> 
> (no show) run with -dTkAGG and -dGTKAgg, does not raise a
> figure
> window in svn HEAD. I thought the OP was complaining
> that the figure
> was being raised w/o a call to show in macosx (don't have
> ready access
> to test on an osx box right now)
> 
> JDH
> 
 

I wasn't able to replicate this bug 
with the MacOS backend. 
--Michiel
On Sat Nov 13th, 2010 1:15 AM EST Jae-Joon Lee wrote:
>I cannot reproduce this with agg, ps and pdf backend.
>Maybe this bug is specific to the Mac oS X backend?
>
>Regards,
>
>-JJ
>
>
>On Sat, Nov 13, 2010 at 5:19 AM, Bror Jonsson <br...@bi...> wrote:
>>
>> Dear all,
>>
>> I must be doing something wrong, but it seems like the backgroundcolor statement for text just stopped working. I am using matplotlib 1.0.0 with MacOSX as backend on two different machines. If I run
>>
>> ipython -pylab
>>
>> text(0,0,'Kalle',backgroundcolor='0.6')
>>
>> I get this result:
>>
>>
>>
>> (The problem is that the text color switches to pale grey). This worked fine before. Does anyone else get this problem, and do you have any idea about how to trouble shoot it?
>>
>> Regards,
>>
>> Bror Jonsson
>> ------------------------------------------------------------------------------
>> Centralized Desktop Delivery: Dell and VMware Reference Architecture
>> Simplifying enterprise desktop deployment and management using
>> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>> client virtualization framework. Read more!
>> http://p.sf.net/sfu/dell-eql-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
>------------------------------------------------------------------------------
>Centralized Desktop Delivery: Dell and VMware Reference Architecture
>Simplifying enterprise desktop deployment and management using
>Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
>client virtualization framework. Read more!
>http://p.sf.net/sfu/dell-eql-dev2dev
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
 

I cannot reproduce this with agg, ps and pdf backend.
Maybe this bug is specific to the Mac oS X backend?
Regards,
-JJ
On Sat, Nov 13, 2010 at 5:19 AM, Bror Jonsson <br...@bi...> wrote:
>
> Dear all,
>
> I must be doing something wrong, but it seems like the backgroundcolor statement for text just stopped working. I am using matplotlib 1.0.0 with MacOSX as backend on two different machines. If I run
>
> ipython -pylab
>
> text(0,0,'Kalle',backgroundcolor='0.6')
>
> I get this result:
>
>
>
> (The problem is that the text color switches to pale grey). This worked fine before. Does anyone else get this problem, and do you have any idea about how to trouble shoot it?
>
> Regards,
>
> Bror Jonsson
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>