[IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS

[Gael Varoquaux]

On Fri, Feb 12, 2010 at 12:25:04PM +0100, Hans Meine wrote:
> > Use:

> >     app = QtGui.QApplication.instance()

> > That should suit your needs and avoid creating an QApplication if it
> > already exists.

> Thanks for the hint, but the docs say:
>   "If no instance has been allocated, null is returned."

Hehe, you caught me bullshiting, I am afraid. :)

How about:

QtGui.qApp

I believe that works, but I am not sure (being cautious this time).

> And how do you want to communicate this to all ipython users?  I mean - there 
> needs to be some documentation about this boilerplate code for every toolkit, 
> and every user needs to be aware of this and get it right.

Honestly, I don't really care about how things are done. I am no longer
really involved in IPython development. All I know is that trying to
solve impossible problems leads to hair loss and disappointment. I
believe you are trying to solve an impossible problem: making sure a user
can use a main event loop without being aware it is around. IPython used
to try and solve that problem using threads. It lead to segfaults because
every single piece of code executed had to be injected in the main loop.
So what was supposed to be transparent worked 99.9% of the time, and the
rest of the time forced people to modify their code in subtle ways and
debug race conditions, which is hard. The developers have now stepped
back and decided that they would make a choice that forces users to be
aware of the problems upfront, but has a simple solution.

I am not saying this is a good or bad choice. I haven't had time to try
out the new IPython, and I am worried of the problems with Mayavi and
Traits. However, I am saying that there is some reasonning behind the
choice, and that whatever we do, we are sitting between a rock and a hard
place.

> I fully agree that the above code has a much better design, is more
> well- behaved, but you know very well that most programs are not so
> well-behaved, and consequently you'll lock out a large fraction of
> existing programs from being %run from IPython.  And from a user's POV,
> this will even appear to be a regression, even if previous support for
> that was buggy - there *was* support for it.

Well, yes, but there were threading problems. You had to be aware of how
threading works under IPython, which is much more technical.

> I'd say not looking at other program's deficiencies, but closing the eyes and 
> adding some proper hack would be much more in the spirit of IPython.

Hacks lead to what we've all been experimenting: segfaults. For somebody
like me who spends most of my day in IPython, it is nice no longer to
have any segfaults.

Gaël