[IPython-dev] Moving forward with the frontends

[Gael Varoquaux]

On Mon, Jun 23, 2008 at 06:10:07PM -0700, Fernando Perez wrote:
> >> As soon as we can refactor the IPython 0.8 core so that it plays
> >> nicely with the IPython.kernel.engineservice.IEngineBase interface,
> >> all frontends could get this behavior for free. If you can't wait for
> >> that refactoring, going with the existing Wx frontend is your only
> >> option at this point.

> > Fernando, Brian, Ville, what is the timeframe for this? What is the
> > amount of work required?

> The way I see things right now, this can be done gradually.

Cool. I think that is indeed the way to go.

> In the meantime, you can consider the WX integration work, in
> conjunction with Barry, as being precisely the beginning of this
> refactoring.  I don't want to draw us again into the 'once the *huge*
> refactoring is done, we can do X' mindset,

I have started working on that today. Currently what I am doing is not
Ipython specific (though I hope it will go in the ipython repository), it
can be adapted to ipython0 or to ipython1. Hopefully the work on
ipython0/ipython1 will move fast-enough so that I will be able to use
that, rather than pushing string to an ipython0 terminal.

> Envisage already has a million nasty dependencies, so I don't see
> Twisted being a problem there.

As long as it brings us something. I have read a bit about the twisted
reactor, and I must admit I haven't understood how it will allow us to
run arbitrary code without blocking the gui loop, but in a thread-safe
way with Wx. I am probably just being heavy.

Anyway, I think in the long run we will want twisted integrated in all
this. I am just saying I have the feeling this is outside the current
scope of my work. Though, if I have understood well, switching from an
engine abstracted through twisted to one running in the same thread as
the calls should be simply a matter of replacing an instance by another,
right?

> The way I hope we'll be able to build this whole thing will be:

> 1. A NON-Twisted using terminal frontend like today, that is fully
> blocking (no deferreds since there's no twisted).  But it uses the
> same interfaces the Twisted ones will use.

I see it slightly differently. I think it is the engine who should come
in different flavors, exposing the same interface. Line 39 of
http://bazaar.launchpad.net/~barrywark/ipython/ipython-frontend/annotate/barrywark%40gmail.com-20080616054258-7jjo8w1tt7sc1zfg?file_id=cocoa_frontend.py-20080611225339-bjp8mnnd2tnxj9n5-8
makes me believe this might already be the case, but I still haven't
wrapped my head around the code, and I can't execute it, as it is Mac
only.

> 2. We keep the threading hacks we have today to provide terminal-based
> acccess to GUIs (the -Xthread options).  Note that this is NOT meant
> to be the way to develop full GUI clients that use ipython, simply a
> way to use the terminal to run GUI code like many people do today.
> It's not perfect but it's lightweight and useful, and I see no need to
> get rid of it.

Sure, I agree the are useful. I can't however worry about them right now.

> 3. For building full-blown GUI clients, we use the Twisted reactors
> that know how to integrate with the various toolkits in existence,
> including Cocoa.


Will this allow me to execute arbitrary wx commands without killing the
application? Can somebody point me to a document hinting how to do this.
I am kind of lost here because I don't really understand how the reactors
works. Anyhow, hopefully this can also be hidden in an object presenting
the same interface as an EngineService.

I think we are on the same wavelength. I am going to focus on trying to get
something done, clean and hopefully extendable, but maybe with a reduce
feature-set. This can be the basis of future work.

Gaël