[IPython-dev] Detecting GUI mainloop running in IPython
Sun Jul 25 16:50:31 CDT 2010
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
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.
More information about the IPython-dev