[IPython-dev] IPython.fronend progress

[Barry Wark]

On Mon, Jun 16, 2008 at 7:02 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:
> On Sun, Jun 15, 2008 at 10:46:35PM -0700, Barry Wark wrote:
>> I hope you don't mind me cc-ing this to the list, in case anyone else
>> is curious.
>
> No, not replying to the list was actually unintended.
>
>> Running the project from within Xcode _should_ (fingers crossed!)
>> start the demo frontend.
>
> That was the part that took us a while to get: we just tried to "python
> foobar.py" the thing, but apparently Apple likes to "think different",
> and this does not work.

You can write Cocoa apps with this method (PyObjCTools.AppHelper
includes functions to start/stop the main loop and you can build the
entire Cocoa stack in code), but the Xcode project wraps the whole
thing in a true native OS X app. It includes one compiled file
(main.m) which loads the python interpreter, adds any
application-specific python packages/modules (which are included in
the app bundle) to the sys.path and exec's the main.py file. My guess
is that using 'python main.py' with an appropriate PYTHONPATH would do
the trick, though I haven't tried it. The "benefit" of Apple's
approach is that the app is a native OS X application bundle with all
the associated LaunchServices support, icons, ability to include
frameworks/python/resources/plugins in the app bundle etc.

>
>> You'll quickly find that the Cocoa frontend is still quite rough
>> around the edges.
>
> My one question is: what is the plan for interacting with the GUI
> mainloop. For example how to I open matlplotlib windows?

That's a great question. You can currently use matplotlib exactly as
you would from a standard python prompt (ie with show()). The caveat
is that all of the matplotlib backends on OS X think they are being
run from a CLI, not GUI and so attempt to create/hijack their own
event loop, often by instantiating a run loop in backend's toolkit.
Since Wx, Tk, and Qt are implemented in Carbon on OS X, they don't mix
very well with the Cocoa run loop. This leads to some weird menu bar
behavior etc. and, with some backends, causes the matplotlib windows
to get stuck on screen. This is a general problem with matplotlib, not
with the Cocoa front end, per-se (the same problems crop up using the
PyInterpreter example in the Developer Tools/Examples folder).

So, how can we get all this working? There are really two parts of
this question...

>
> I guess this is a more general question: what is the road forward on
> frontends for this problem?

1. There's no reason that matplotlib needs to create its own run loop.
I've been working off and on on a true Cocoa backend form Matplotlib.
My intention is to make it play nicely with an existing Cocoa run loop
etc. This would address the issue you asked about above, namely using
matplotlib interactively from the frontend's own engine.

2. There's a deeper issue in the ipython1 architecture that Brian and
I have just started to have a couple of discussions about (he may have
had similar conversations with other folks too, of course). What
happens if a client executes code on a remote engine such as
"pyplot.plot([1,2,3]);show()" that produces something besides stout
output? What do we want to happen? One possibility is that we'd like
the resulting plot to be displayed to the user by their client, either
in-line in a notebook style interface or in a separate window in a
command-line style interface. Brian and I discussed adding a rendering
package to IPython.kernel.core. Renderers would be registered by
object type, so that a specific renderer could be registered for
matplotlib figure or Lines2D or whatever. A default, pprint renderer
would catch all cases of types that don't have a registered renderer.
When the core returns the result of an exec, it could instead
substitute the renderer for that result. Alternatively, the client
could explicty request the renderer for a particular object in the
engine's namespace.

In the case of matplotlib plots that renderer could produce a static
image of the plot to be passed to the client (easy) or a proxy object
that could continue to interact with the plot remotely (harder, but
doable). Objects might also be able to specify their own rederer via a
__renderer__ property, for example. In this way, the matplotlib or
chaco or MayaVi etc. developers could add IPython renderer support to
their library directly.

Well, at least that's the idea... as always, there's a lot to do and a
real functional/technical spec or code will speak much louder than
words.

Cheers,
Barry