I've been keeping more or less up on the .11 development ipython,
under Ubuntu 9.10 (10.4 when I get around to it...). For each of the
backends I do the following in an interactive session that starts with
no profile or -pylab or anything::
import matplotlib
matplotlib.interactive(True)
matplotlib.use('whateverbackend')
from matplotlib.pyplot import scatter,show
from numpy.random import randn
%gui -a whateverguiname
scatter(*randn(2,100))
show()
that "%gui" bit is the new trick in ipython .11 that you use to
initiate the event loop, so that the --pylab flag is superfluous. I
try it both with, and without that line. Below are my results for the
various backends:
*wx:
w/o %gui: nothing appears until show(), show() correctly blocks until
the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
*qt4:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() does NOT block.
*gtk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
w/ %gui: identical behavior
*tk:
w/o %gui: the window appears on the call to scatter(), show() blocks
until the window closes.
w/ %gui: the window appears on the call to scatter(), show() blocks
until the window closes, and continues to block until ctrl-c is
pressed in the ipython interpreter.
So it seems the interactive case of using the %gui magic works in all
cases for interactive mode, but show is still not consistent in
ipython .11 ...
On Fri, Jul 16, 2010 at 2:26 PM, Eric Firing <efir...@hawaii.edu> wrote:
> All,
>
> John noticed that my changes to show() prior to 1.0 had broken a use
> case with tkagg and ipython -pylab, so I fixed that yesterday in
> maintenance branch and trunk. Today, in 8562 and 8563, I did some
> refactoring to try to make show() behavior more understandable across
> backends, and easier to modify if necessary. Specifically, we need to
> work with the ipython people to make sure the ipython 0.11 refactoring
> of interactive support works as intended. I haven't done any testing
> with the development version of 0.11 yet.
>
> At present, all interactive backends start a blocking mainloop only if
> ipython has not attached a _needmain flag to show(), and if mpl is not
> in interactive mode.
>
> Under all script and ipython conditions, multiple calls to show in a
> session or script are permitted.
>
> All interactive backends behave the same when run with ipython -pylab,
> version 0.10: show is non-blocking, regardless of whether it is executed
> on the command line (completely unnecessary) or is found in a script.
>
> Under raw ipython (no -pylab or other threading flags provided), with
> mpl in non-interactive mode, all backends behave the same: show() is
> needed and blocks, but may be called multiple times. With mpl in
> interactive mode, there are two categories: tkagg, fltkagg, gtk*, and
> qt4agg behave the same as in -pylab mode, so there so no longer any real
> need for the special threading modes; but wx* and qtagg do not behave in
> a useful way, so they still need the special threading.
>
> All of the above is based on quick tests with my own system, ubuntu
> 10.04. I expect it will be the same for other supported systems, with
> the exception that behavior in raw ipython mode, with mpl in interactive
> mode, may not work with some earlier versions of gui toolkits--but I
> suspect we will not actually encounter this for supported versions.
>
> I have not built or tested anything under Windows or OS X. For the
> latter, testing of the macosx backend is needed. I expect cocoaagg to
> behave differently than the others, but no differently than it did
> before my changes.
>
> Eric
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
