[IPython-dev] Moving forward with GUI's (was Re: Help! TR: TR: Ipython plugin
Tue Jun 3 18:43:16 CDT 2008
It's also worth mentioning by way of introduction what I'm working on
in ipython1.frontend.rendering. The idea is that things like
matplotlib/chaco plots, images, or other non-string results may want
to be displayed inline by a graphical frontend (like Mathematica's
notebook interface). Obviously, this rendering is going to be GUI
framework dependent, so I'm trying to make it easier for frontends to
create renderers for images, plots etc. and figure what renderer to
use for what result. So the rendering module provides a registry,
keyed by object type of renderers so a frontend can find the most
specific renderer for a result object. I'm not sure this is ultimately
worth it... we'll have to see how much utility it provides to
On Tue, Jun 3, 2008 at 4:28 PM, Barry Wark <firstname.lastname@example.org> wrote:
> On Tue, Jun 3, 2008 at 1:39 PM, Ville M. Vainio <email@example.com> wrote:
>> On Tue, Jun 3, 2008 at 6:10 AM, Barry Wark <firstname.lastname@example.org> wrote:
>>> 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
>> It doesn't seem to be too hard to shoehorn the frontendbase between
>> the gui and ipython; most of the work is really in implementation of
>> the actual gui drawing.
> Correct. This is the only way to make sure that a terminal frontend,
> a graphical frontend like Mathematica's or a web-based frontend can
> all fit into the same framework. This leads to the somewhat simplified
> M(VC) picture where the FrontendBase acts as the model for an ipython
> engine, and the front end implementation acts as a combined view and
> controller in the MVC architecture.
>> Though, at the moment frontendbase can't be directly imported in core
>> ipython due to twisted dependency. I suppose the only real twisted
>> dependency in that class could be removed by creating
>> "result_ready(r)" method and implementing execute_with_callback in
>> engine that does normal callback instead of returning a deferred...
>> obviously the engine can use deferred for actual implementation, for
>> the twisted version.
> Because FrontendBase.__init__ takes an engine parameter, the terminal
> frontend could use core instead of engineservice for its engine. The
> only requirement then is to have a small amount of code (I think this
> already exists somewhere in ipython1.core) for chaining callbacks to
> the execution result (i.e. creating a pseudo-Deferred).
>> Ville M. Vainio - vivainio.googlepages.com
>> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
More information about the IPython-dev