Re: [matplotlib-devel] For review and merging: new GUi support for Qt4 and Wx

[Eric F. <ef...@ha...>]

On 09/07/2010 11:07 AM, Fernando Perez wrote:
> Hi Eric,
>
> On Tue, Sep 7, 2010 at 1:31 PM, Eric Firing<ef...@ha...>  wrote:
>>
>> I have been doing a little testing with ipython 0.10 versus
>> ipython-newkernel, both modes, and with mpl svn versus your guisupport.
>> There are so many possible modes of operation and combinations of
>> versions and backends that all this will take some time to sort out.
>>
>> Can you give me simple examples of what does *not* work correctly when
>> you use mpl *svn* with ipython-newkernel, in either or both of the
>> console or gui modes, but *does* work with your guisupport version?
>
> Thanks for your testing, Eric.
>
> With matplotlib *alone*, I can't find a way to crash/lock/whatever the
> combo of matplotlib(svn)+ipython-newkernel.
>
> The reason, i believe, is that guisupport.py is available in ipython
> itself, and it goes out of its way to avoid creating a second main qt
> app, letting matplotlib create it. Since that main app is alive all
> the time, there's only one app and one event loop and life is good.
> But if I were to open another library that uses Qt and makes a new
> main qApp unconditionally, we'd have problems.
>
> Brian and Evan have recently just added the guisupport.py patch to
> Enthought's ETS, so that now it probably will be pretty hard to
> actually see the problem: if both ipython and ets go out of their way
> to avoid the nested main app issue, mpl can get away with making one
> unconditionally and things will probably work OK.
>
> But the idea is for all of us (ipython, ets, mpl, etc) to agree on a
> collaborative protocol with a simple api: check for one special
> '_in_event_loop' flag in the main toolkit before making one.  That
> will make it easier to have interactive code that uses Wx or Qt from
> more than one library coexisting in the same process.

Fernando,

There are two parts to guisupport: ensure a single main app, and ensure 
no more than one call to the mainloop.  The first makes perfect sense, 
and cannot cause any problems that I can see.  The second one is the one 
that I think may be both unnecessary and undesirable.  The reason is 
that the gui toolkit mainloop functions or methods are designed for 
nested calls.  This permits blocking within a running mainloop, and 
allows show() to block when pyplot is not in interactive mode.  This is 
what is lost with the guisupport mods.  Some changes to mainloop logic 
may well be needed, but I don't think that prohibiting nested calls to 
the underlying toolkit mainloop function is necessary or desirable.

Eric

>
> I'll let Brian fill in with more details when he has some
> availability, but I think that's the gist of it.
>
> Regards,
>
> f