[IPython-dev] Interactive wx/pylab with no threads (PyOS_InputHook)

[Barry Wark]

On Mon, Feb 9, 2009 at 12:53 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Sun, Feb 8, 2009 at 10:00 PM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>> On Sun, Feb 08, 2009 at 08:49:07PM -0800, Barry Wark wrote:
>
>>> > From my reading, it seems that Brian is well on his way to having a
>>> > threading-free core for Qt and GTK. With the awesome new (in a recent
>>> > version, I forget which) OS X backend for matplotlib and the existing
>>> > ability of  Twisted's _threadedselect reactor to work with OS X's
>>> > CFRunLoop via PyObjC (it uses a very similar mechanism to the
>>> > PyOS_InputHook, no?), I suspect that a similar approach will work with
>>> > OS X as well. I know this may sound heretical to some, but if
>>> > supporting Wx GUI loops natively requires compromising the hackability
>>> > and testability of the IPython core, do we *need* to support it?
>>
>> All the libraries I use, I use them through Wx GUI loops. And it is the
>> case of most people under Windows (I am under Linux). The reason behind
>> both statement is that Wx has been historically the easy way to have a
>> powerful GUI shared between major operating systems. Maybe Qt is the way
>> forward now, but it is not yet established. The problem with Wx
>> (recursive Yeilds) comes from the fact that it supports different event
>> loop with different semantics on different platforms, so it comes from
>> that richness.
>>
>> Wx is the toolkit where you will find the largest amount of mature
>> contributions. I know that matplotlib has a variety of different toolkit
>> support, but matplotlib is an exemption.
>>
>> Do we need wx support? I guess not, but I would be jumping ship, and many
>> people would.
>
> Barry,  I think you make a very valid point, but quite unfortunately,
> I have to side with Gael on this one: Wx *today* gives us Chaco,
> Mayavi2, Envisage, TraitsGUI and friends.  That's a LOT of
> functionality that many of us need and use, and we can't really dump
> that user base.  We can look into perhaps refactoring 'ipython
> -wthread' into some ghetto where it doesn't "pollute" the rest of the
> code quite so much, and I'm totally open to that.  But I think *right
> now* dropping Wx would be a mistake.
>
> However, note above my emphasis on "now".  That's because I'm very
> much hoping that PyQt will go LGPL and that over time, Qt will come to
> replace Wx in the roles we're interested in.  If/when that comes to
> pass, we may very well see this discussion in a very different light.

Yes, I agree. It would be a shame to loose all of the Enthought suite
(though don't they also have a Qt backend? I suppose it's not as well
maintained as the Wx backend?), as well as the many other tools.
Once/if PyQt is LGPL, hopefully the community can *start* to
consolidate. If IPython comes out strongly in favor of Qt for future
development, that might help, though I undestand if the IPython
community doesn't want to make that stand.

cheers,
B

>
> Cheers,
>
> f
>