[IPython-dev] Re: [IPython-user] ipython gui interpreters

[Fernando Perez]

Ville Vainio wrote:
> On 8/22/05, Frédéric Mantegazza <mantegazza at ill.fr> wrote:
> 
> 
>>I started to port konsole, the terminal emulator of KDE, for pyqt, with the
>>help of Lars Doelle, the konsole author, which sent me a qt-based only
>>code.
>>
>>But as there are a lot of C++ specific stuff in the code (heavy usage of
>>macros, lots of pointers...), I think it is better to start from scratch
>>and make something more pythonic.
> 
> 
> Did you consider merely adding a series of hooks for injecting python
> code where it's needed, instead of rewriting everything? Or can't you
> embed konsole in a pyqt app as it stands?

That's pretty much the approach the gui notebook project is taking, and I 
think it's the right long-term one.  Currently ipython's hooks aren't as 
clearly specified as they should, but it's precisely a project like this that 
forces us to clean up that API.

The GUI notebook uses a wx.ScrolledWindow widget as its base class:

class ipnNotebook (wx.ScrolledWindow):
     """
     A widget having the base functionality of a Mathematica and Maple
     - like notebook. It holds cells with various types of
     information. Each cell is responsible for painting itself and
     handling user input. The cells can only be ordered vertically, you
     cannot have cells next to each other.

     """
[...]

This calls into ipython to actually execute code, provide magics, etc.

I continue to believe that the right long-term solution is to continue down 
this road, cleaning up and dividing functionality between kernel and front end 
more and more.  The current terminal-based ipython could then become just 
_one_ of the front ends to a common kernel, and in the end I expect the front 
ends and the kernel to live in separate processes.  This will allow a number 
of important problems to be addressed (signals can't be tossed in python 
across threads, but they _can_ across processes, for one, and there are lots 
more).

If Charles wants to play with that code, keep in mind that it's all out there, 
in a public SVN repo for anyone to grab.  This is the trac interface if you 
want to see what's going on:

http://projects.scipy.org/ipython/ipython

and the raw SVN repo is here:

http://ipython.scipy.org/svn/ipython

Note that currently installing nbshell is a bit painful, as they require very 
bleeding edge versions of a few things.  But since this is currently under 
heavy development, I OK'd the students to use any tool they needed.  Hopefully 
by the time a user-level release is coming, the dependencies will have caught 
up with us and we can require only (at the time)-stable versions.

Have a look at that, and let me know if you have further 
questions/ideas/comments.  There's obviously a need for something like this 
across many fields, and I keep trying to unite developers around a common 
engine, rather than have everybody reinvent the same wheels over and over from 
scratch.  I think ipython can be such an engine and it already has a ton of 
functionality in it, we only need to continue the process of exposing out the 
parts that make sense as a public API for this kind of embedding.

Regards,

f