[IPython-dev] Uniform way of integrating event loops among different IDE's

[Fernando Perez]

Hi Almar,

On Tue, Aug 24, 2010 at 8:06 AM, Almar Klein <almar.klein at gmail.com> wrote:
> I'm developing an IDE for Python (http://code.google.com/p/iep/) that is
> capable of integrating the event loop of several GUI toolkits. On a side
> note, I used much code of IPython as inspiration on how to do that, so
> thanks for that.

Welcome!  It looks like iep has some very nice features.  I'm glad
IPython has been useful to you, both in code and in inspiration, I see
you have put in magics, the ? sytnax, etc.  Great :)

> I saw in the IPython documentation that IPython users can detect whether
> IPython hijacked the event loop as follows (for wx):
>
> try:
>     from IPython import appstart_wx
>     appstart_wx(app)
> except ImportError:
>      app.MainLoop()
>
> A very nifty feature indeed. However, building further on this, wouldn't it
> be nice if people could perform this trick regardless of in which IDE or
> shell the code is running? Therefore I propose to insert an object in the
> GUI's module to indicate that the GUI event loop does not need to be
> entered. I currently use for my IDE:
>
> import wx
> if not hasattr(wx, '_integratedEventLoop'):
>     app = wx.PySimpleApp()
>     app.MainLoop()
>
> Currently, _integratedEventLoop is a string with the value 'IEP', indicating
> who hijacked the main loop. I'm not sure what IPythons appstart_* function
> does, but the inserted object might just as well be a function that needs to
> be called (using the app instance as an argument, but how to call it for
> fltk or gtk then?).
>
> I'm interested to know what you think of this idea.
>   Almar
>
> PS: for PyQt4, I would propose inserting the object both in the PyQt4 and
> PyQt4.QtGui namespaces.

This certainly sounds like a viable idea, it's basically having a
simple convention for how third-party codes can detect whether the
main gui loop is already controlled.

I should note that *right now* Brian is re-working our gui support,
because for the new 2-process work we can't hook into pyosinputhook
anymore (since the kernel isn't running in a terminal that reads user
input anymore, but instead listening on a network port).  I'm working
on a different part of the code right now so he may pitch in later,
but this is just to say that the details of how we do things in the
new zmq-based 2 process code may differ somewhat.

But regardless of what changes we end up having in console vs.
network, I do think that standardizing a 'protocol' for applications
that can expose an interactive event loop to sync with user's gui code
is definitely what we want to have.   Once a clean solution is in
place, matplotlib, chaco and friends can be adjusted to a common
standard and work with ipython, iep, etc. in a single shot.

On a different topic: I downloaded iep's hg tip to have a look, but I
realized that your code is GPL, so I preferred not to go much deeper
into it.  I would like to at least ask that you consider releasing
your code with a license that makes it easier to share code between
iep and ipython, numpy, matplotlib, etc.  You mention how code and
ideas in ipython have benefitted you in various places, and I think
that's great.  However, by building a GPL code, you are in fact
creating an asymmetric relationship: you can use our code and ideas,
but we can't use yours.  IPython, numpy, matplotlib, scipy, mayavi,
chaco and all the other scientific python tools you benefit from daily
are all released under the BSD license (like Python itself), which
makes it very easy to share code across all of them.  But a single
(small or large) application that is GPL in this ecosystem becomes a
one-way street: that project can use all the others, but it doesn't
give anything back.

I obviously respect your decision to release your code as GPL, it is
your legal right to do so.  I would only ask that you consider how the
hundreds of thousands of lines of code combined in ipython, mpl,
numpy, scipy, etc (and the time this community has contributed to
create and maintain them) have benefitted you when working and
creating IEP, and how you'd like to participate in this community as a
fellow contributor.  We've built a great community of projects that
all share back and forth with each other, it would be great if IEP was
a new member of this same community instead of only taking from it.

All the best,

f