[IPython-dev] Detecting GUI mainloop running in IPython
ellisonbg at gmail.com
Sun Jul 25 17:55:37 EDT 2010
On Sun, Jul 25, 2010 at 2:50 PM, Eric Firing <efiring at hawaii.edu> 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
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev