[IPython-dev] Detecting GUI mainloop running in IPython

[Eric Firing]

On 07/25/2010 11:22 AM, Brian Granger wrote:
[...]
>
>     What are the non-hook methods you have in mind?  Maybe this option makes
>     my proposed, or hoped-for, simplification impossible.
>
>
> The two process kernel/frontend will simply start the event loop in the
> kernel in the traditional way (non inputhook).  It has to do this
> because the entire kernel will be based on that event loop.  We have
> thought about if we could reuse the inputhook stuff there and it won't work.

I suspect this will require major changes in mpl's gui event code.
What is your time scale for switching to the two-process version?  Is 
there a document outlining how it will work?  Or a prototype?

>
>      > While we are focused on other things right now (the
>     kernel/frontend) we
>      > would love to hear your thoughts on these issues.  Implementing a
>      > solution shouldn't be too difficult.
>
>     Another vague thought:  If we really need a more flexible environment,
>     then maybe the way to achieve it is with a separate package or module
>     that provides the API for collaboration between, e.g., ipython and mpl.
>       Perhaps all the toolkit-specific event loop code could be factored out
>     and wrapped in a toolkit-neutral API.  Then, an mpl interactive backend
>     would use this API regardless of whether mpl is running in a script, or
>     inside ipython.  In the latter case, ipython would be using the same
>     API, providing centralized knowledge of, and control over, the app
>     object and the loop.  I think that such a refactoring, largely combining
>     existing functionality in ipython and mpl, might not be terribly
>     difficult, and might make future improvements in functionality much
>     easier.  It would also make it easier for other libraries to plug into
>     ipython, collaborate with mpl, etc.
>
>
> This might make sense and as we move forward we should see if this makes
> sense.  My first thought though is that I don't want to track yet
> another project though.

I certainly sympathize with that. It could live in ipython as a single 
module or subpackage.  Maybe ipython would end up being an mpl dependency.

>
>     Even if the idea above is sound--and it may be completely
>     impractical--the devil is undoubtedly in the details.
>
>
> And there are many ones in this case.  Thanks for participating in the
> discussion.

Everything you said in your response to my post points in the direction 
of really needing a clean central API to coordinate the gui activities 
of all the potential players.

Eric
>
> Brian