On 07/19/2010 10:34 AM, Erik Tollerud wrote:
> 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
Aha!
Please leave out the -a. It is harmful, not helpful, for mpl. This may
mean we need to change mpl and/or ipython, or the documentation, to
prevent problems with the -a option; but I think you will find that if
you leave out that option, the behavior will be more consistent and the
need for Ctrl-C will go away. Without %gui, there will still be an
inconsistency between wx and the others--but that's what the %gui magic
is for, to make wx use PyOS_InputHook like the others.
Eric
>
> 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
