[IPython-dev] GUI support: conflicts between IPython 0.11 and Matplotlib/ETS
Thu Feb 11 14:19:04 CST 2010
> I'm new to the Ipython dev list, and don't really understand the
> internals, but this thread was posted elsewhere to solicit ideas, so
> here I am:
Thanks for joining the discussion, it helps alot.
>> Both matplotlib and ets have code that tries to:
>> * See what GUI toolkit is being used
>> * Get the global App object if it already exists, if not create it.
>> * See if the main loop is running, if not possibly start it.
> Are these done in order to support IPython? or for other general usage?
Yes, as I understand it that is why this logic exists (for IPython's
-wthread or -pylab).
> So it doesn't use threads at all? that is good news.
Yep, no threads at all. Other than the bugs we are talking about here
it is *much* more robust and stable.
>> GUI toolkits, special options have to be passed to the application object
>> to enable it to function properly in IPython.
> so the app itself needs to do something special? that is too bad -- so
> far, I've found IPython works pretty well with my own wxPython apps,
> with nothing changed in my app.
Yes, you are understanding the issue well. We don't see anyway around
this. If you want to use GUI code both in IPython and outside of
IPython, you will need to have a small amount of custom logic.
Fernando and I spent an entire day at Scipy 2009 trying to figure out
a way to prevent this...no luck.. I am afraid this is a fundamental
limitation unless all the GUI toolkits radically change their APIs.
>> * Who is responsible for creating the main GUI application object, IPython
>> or third parties (matplotlib, enthought.traits, etc.)?
> I think the third parties -- i.e. you really want to be able to use
> IPython with ANY GUI app - not just one written to be used with IPython.
Again, unless qt/wx/gtk change their code, I don't think this is
possible. Plus even if they did, Ipython still has to work with
current/older versions. By third party here I am thinking of projects
like matplotlib/enthought that, in general, are commited to
maintaining good integration with Ipython.
>> * What is the proper way for third party code to detect if a GUI
>> object has already been created? If one has been created, how should
>> the existing instance be retrieved?
> This is why it seems better for IPython NOT to create the GUI app
> object. If it doesn't, would the third party code have to detect it?
In general there are reliable ways for third party code to detect if
an app object has been created already. But, creating an app is not
always trivial. In some cases (like wx) in order to work properly
with IPython, specific arguments have to be passed (non-default ones)
to the app. In these cases, it makes sense for IPython to handle it.
> hmm, yes it would, or something -- if I want to call my program with
> "run" more than once, then a wxApp has been initialized already, and I
> think you can only do that once per process.
> Could Ipython monkey-patch the GUI toolkits to override the app creation
> and mainloop starting? I'm not sure this is possible, but a typical wx
> app might look like this:
> app = wx.App()
The app creation step is pretty easy to handle. Most GUI code should
call getApp first to make sure the app has not already been created
before creating an app from scratch.
The more difficult question is knowing if you should start the main
loop. For example, if IPython is already running the event loop using
pyos_inputhook, calling app.MainLoop will lead to bad things.
Unfortunately, calling isMainLoopRunning() returns False, so you don't
have a good way of discerning what to do....currently.
> if wx had been monkey-patched by IPython, the app creation and mainloop
> calls could be overridden with ones that check to see if they have been
> called before, and do something different if so. As for wx, I don't know
> if you can stop and re-start the mainloop anyway.
See my other post, but the mainloop monkeypatch approach does not
work. It breaks qt/wx/etc.
> I'm still confused how this all seems to work for me with IPython 0.9.1!
It doesn't *really* work :) The pre 0.11 code is not thread safe and
does very subtle tricks to get cross thread signals working....which
is why it crashes often and breaks if you touch the code.
> I hope this is helpful,
Very much, thank you.
> Christopher Barker, Ph.D.
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
> IPython-dev mailing list
More information about the IPython-dev