[IPython-dev] Detecting GUI mainloop running in IPython
Sun Jul 25 16:55:37 CDT 2010
On Sun, Jul 25, 2010 at 2:50 PM, Eric Firing <email@example.com> wrote:
> On 07/25/2010 11:22 AM, Brian Granger wrote:
>> What are the non-hook methods you have in mind? Maybe this option
>> 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
> 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?
Here is a sketch of the design:
This development is happening right now as part of two GSoC projects and
some Enthought funded work. There are 5 of us working off of
ipython/ipython master right now in our own branches. Should be ready for
testing in the next month. The actual 0.11 release is probably a bit
further out than that though.
>> > 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
>> 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
>> 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.
IPython is already almost an mpl dep. But I guess some people run mpl in
servers where IPython is not present.
>> 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.
Yes, definitely. We will keep you in the look.
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev