[IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin

[Barry Wark]

On Mon, Jun 2, 2008 at 4:56 PM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Mon, Jun 2, 2008 at 3:26 PM, Ville M. Vainio <vivainio at gmail.com> wrote:
>> On Mon, Jun 2, 2008 at 11:39 PM, Laurent Dufrechou
>> <laurent.dufrechou at gmail.com> wrote:
>>
>>> About specific API for GUI devs,
>>> Here is my feeling about what was missing in ipython0 and that could be
>>> refactored/improved while switching to ipython1:
>>
>> Since I have some professional interest to boost my qt skills, I
>> thought that providing qscintilla (and pyqt4) version of ipython might
>> be a good way to really find out what needs to be generalized in
>> IPython. Of course you have already done a good job with wxipython,
>> but it would really help overall ipython architecture if we made the
>> code in GUI's as natural as possible (i.e. without needing the hacks
>> you had to do for wxipython). At least eric4 could then embed ipython
>> instead of vanilla python.
>>
>> As assumedly Fernando now re-assumes the coordinator role for the
>> stable branch, plus the influx of other dev's to ipython0 code base,
>> it should be much easier for me personally to allocate the "ipython
>> time" into playing with a largish feature like this.
>
> That is an excellent plan.  Let's make sure that as we work on this,
> we keep in mind:
>
> - the work that Barry has been doing on Cocoa

I would encourage you guys to take a look at the
ipython1.frontends.frontendbase class. My intention is to develop this
into a base class for all GUI frontends. The underlying assumption is
that GUI frontends will interact with the ipython interpreter via the
ipython1.kernel.engineservice (Twisted) API. The benefits, as I see
them for this approach is to avoid rewriting the Wheel of GUI
Integration (the Twisted guys have already done this), and to make it
_very_ easy to provide remote/parallel capabilities from within the
GUI frontend.

Of course, code speaks louder than words and I invite you to hack on
the frontends package (currently in ipython1-cocoa branch, but I
assume soon to be merged inwards towards ipython1-dev or trunk). The
frontendbase is currently a work in progress, but I've attempted to
make it clear where subclasses (e.g. GUI frontend implementations
should subclass particular methods to gain the desired functionality).
The intention is that frontends are an aggregate of a frontendbase
subclass and a GUI widget or a GUI widget (such as a text widget) that
subclasses both the GUI toolkit's widget and the frontendbase.

barry

>
> - correct integration with twisted's event loop.  There's a lot of
> interest in the -twisted option working right, and twisted has GUI
> integration mechanisms (as discussed here earlier); we just want the
> whole thing to play nice with the networking layer used for
> distributed use.  Note that the distributed use is not just for
> parallel computing: you may also want a Qt/Wx gui working on a remote
> ipython instance...

If we stick with developing GUI interfaces through the engineservice
interface, we get all this for free. In addition, I think such an
approach will help drive the ipython1->ipython0 integration because it
will highlight the most pressing areas where we the ipython1's core
(exposed via engineservice) is not up-to-par wrt the ipython0
InteractiveShell.

>
> - the needs for the same abstractions to work over the network from
> frontends like a web browser that uses JavaScript.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>