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

On 09/13/2010 08:54 AM, Brian Granger wrote:
> Eric,
>
> Sorry about the delay, I was on vacation last week...comments inline below...
>
> On Tue, Sep 7, 2010 at 2:26 PM, Eric Firing<ef...@ha...>  wrote:
>> 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.
>
> Yes, that is a good summary.
>
>>   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.
>
> This is a very good point and is something that we have thought
> carefully about.  You are very correct, that the functions in
> guisupport cannot be used to do a nested mainloop.  Nested calls to
> the mainloop should be done in the usual manner by simply calling the
> appropriate gui toolkit method for doing so.  We probably need to
> clarify this point, but the focus of the functions in guisupport are
> *only* the first and main invocation of the event loop.  Basically, we
> want to ensure that:
>
> * Projects don't accidentally do nested mainloops because there were
> not aware that the outermost eventloop was already running.
> * Projects start the outermost eventloop in a manner that other
> projects will be able to reliably detect.
>
> I should mention the other approach that we have tried, but that failed:
>
> * Have IPython startup, create an app and start the main loop.
> * Then monkeypatch the gui toolkit so that the mainloop calls are no-ops.
> * Further monkeypatch the gui toolkit so that it appears that the
> mainloop is running (even when it may not be because of PyOS_InputHook
> magic).
>
> This allowed us to do everything, BUT obviously, nested mainloops
> failed.  Thus, making sure that nested mainloops still work was the
> main reason we have created guisupport.  We should better document
> these details though.

Brian,

Thanks for the clarification.  Your basic approach sounds fine. I need 
to think a little more about how to handle this in mpl.  The proposed 
modification is not quite right yet.  I probably can't work on it until 
the weekend.

Eric

>
> Cheers,
>
> Brian
>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>