&lt;snip&gt;<div class="h5"><br>
</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">This certainly sounds like a viable idea, it&#39;s basically having a<br>

simple convention for how third-party codes can detect whether the<br>
main gui loop is already controlled.<br>
<br>
I should note that *right now* Brian is re-working our gui support,<br>
because for the new 2-process work we can&#39;t hook into pyosinputhook<br>
anymore (since the kernel isn&#39;t running in a terminal that reads user<br>
input anymore, but instead listening on a network port).  I&#39;m working<br>
on a different part of the code right now so he may pitch in later,<br>
but this is just to say that the details of how we do things in the<br>
new zmq-based 2 process code may differ somewhat.<br></blockquote><div><br>Interesting. IEP runs its interpreter in a different processes also. You (or Brian) might be interested in the channels module which IEP uses for communication (via a socket, full Unicode support). You&#39;d be happy to know I choose to license it separately as BSD, since I thought it might be useful for other projects.<br>
<a href="http://code.google.com/p/iep/wiki/Channels">http://code.google.com/p/iep/wiki/Channels</a><br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

But regardless of what changes we end up having in console vs.<br>
network, I do think that standardizing a &#39;protocol&#39; for applications<br>
that can expose an interactive event loop to sync with user&#39;s gui code<br>
is definitely what we want to have.   Once a clean solution is in<br>
place, matplotlib, chaco and friends can be adjusted to a common<br>
standard and work with ipython, iep, etc. in a single shot.<br></blockquote><div><br>Great to hear you&#39;re interested. As soon as things fall into place for IPython, we should get in contact and discuss how we want to do that.<br>
 <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On a different topic: I downloaded iep&#39;s hg tip to have a look, but I<br>
realized that your code is GPL, so I preferred not to go much deeper<br>
into it.  I would like to at least ask that you consider releasing<br>
your code with a license that makes it easier to share code between<br>
iep and ipython, numpy, matplotlib, etc.  You mention how code and<br>
ideas in ipython have benefitted you in various places, and I think<br>
that&#39;s great.  However, by building a GPL code, you are in fact<br>
creating an asymmetric relationship: you can use our code and ideas,<br>
but we can&#39;t use yours.  IPython, numpy, matplotlib, scipy, mayavi,<br>
chaco and all the other scientific python tools you benefit from daily<br>
are all released under the BSD license (like Python itself), which<br>
makes it very easy to share code across all of them.  But a single<br>
(small or large) application that is GPL in this ecosystem becomes a<br>
one-way street: that project can use all the others, but it doesn&#39;t<br>
give anything back.<br>
<br>
I obviously respect your decision to release your code as GPL, it is<br>
your legal right to do so.  I would only ask that you consider how the<br>
hundreds of thousands of lines of code combined in ipython, mpl,<br>
numpy, scipy, etc (and the time this community has contributed to<br>
create and maintain them) have benefitted you when working and<br>
creating IEP, and how you&#39;d like to participate in this community as a<br>
fellow contributor.  We&#39;ve built a great community of projects that<br>
all share back and forth with each other, it would be great if IEP was<br>
a new member of this same community instead of only taking from it.<font color="#888888"><br></font></blockquote><div><br>You bring forward compelling arguments. I will seriously reconsider the license. <br><br>I find this license landscape quite difficult to comprehend sometimes. I mean, GPL has it going for it that it protects the code from being used commercially, which is good right? At least if I should believe Richard Stallman :)  In a landscape dominated by GPL code this would make sense, since projects would be able to borrow from each other. However, you&#39;re right: in the Python landscape BSD is the norm, which means a GPL project would not &quot;fit in&quot;.<br>
<br>Please note that it&#39;s not my intention to only &quot;take&quot;, or I would not have released IEP in the first place. The only problem is that other projects cannot easily borrow code from IEP if they&#39;re not GPL itself. I&#39;ll need to give this some thought.<br>
<br>Cheers,<br>  Almar<br><br></div></div><br>