[IPython-dev] Detecting GUI mainloop running in IPython

[Brian Granger]

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
>> 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?
>
>
Here is a sketch of the design:

http://github.com/ipython/ipython/commit/e21b32e89a634cb1393fd54c1a5657f63f40b1ff

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
>> 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.
>
>
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
>> 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.
>
>
Yes, definitely.  We will keep you in the look.

Cheers,

Brian



> Eric
>
>>
>> Brian
>>
>


-- 
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...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100725/fdd9e61a/attachment.html>