[IPython-dev] wxPython console
Fernando Perez
fperez.net at gmail.com
Thu Nov 3 18:23:34 EDT 2011
On Thu, Nov 3, 2011 at 5:17 AM, Emmanuel Bacry
<emmanuel.bacry at polytechnique.fr> wrote:
> Thomas Kluyver-2 wrote:
>>
>> At the moment, I don't think there's a good way to embed IPython in a GUI
>> without starting a separate process, but this is something we want to get
>> round to.
>>
> Too bad !
There is a way of embedding that may actually work for you, and can
save you quite a bit of time in that you could actually use your
current Wx library as-is, and reuse our Qt console. This example:
https://github.com/ipython/ipython/blob/master/docs/examples/lib/ipkernel_wxapp.py
shows how you can embed an IPython *kernel* in your own application.
Given this kernel, you can then connect with any client capable of
speaking the ipython protocol (right now that's the qtconsole or the
notebook --with a small fix for talking to existing kernels needed),
but there's also a terminal one in the works in PR #864).
The point of this would be that this kernel would run in your existing
Wx framework right away, and you could connect the current Qt console
(also already written) to it immediately. You just need to pass the
dictionary with the namespace you want the user to see.
Obviously if your own Wx console has extra functionality that you need
this isn't the best approach.
If you want your Wx console to be able to talk to an external kernel,
the easiest would be to study how the current qt console works: it's
basically a matter of converting the signals and slots machiery to the
equivalent Wx event handling code.
Finally, we do envision being able to embed a qt/wx console into a
single process, and we're not too far from the necessary architectural
cleanup to make that easy. The model would be that a client
(terminal, qtconsole, wx, etc) would have a kernel manager object that
could be either local or remote, but with otherwise identical api.
Right now we only have remote ones, and the local terminal doesn't
abstract out its interactions through a kernel manager. But once that
design is in place (and we're not that far from it, we just need some
more refactoring to be completed), it should be effectively
transparent whether a client is using a local or remote kernel; local
ones wouldn't even need zmq as their 'messaging' would just be
in-process method calls.
Hopefully this clarifies both the short-term options for you as well
as our longer-term design...
Cheers,
f
More information about the IPython-dev
mailing list