[yt-dev] Implementing Backend Independent Plots: Pull Request 2294

Mon Aug 1 10:37:53 PDT 2016

On Mon, Aug 1, 2016 at 12:17 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Austin and Nathan,
>
> On Thu, Jul 28, 2016 at 10:51 AM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> I just want to voice my main issues with the PR as it's currently
>> implemented. I've communicated this with Austin in private but want to make
>> sure this is all publicly written down so others can offer advice.
>>
>> Right now the PR makes it possible to do something like this:
>>
>>     import yt
>>     yt.toggle_interactivity()
>>
>>     slc = yt.SlicePlot(ds, 2, 'density')
>>     slc.show()
>>
>> and then have a GUI window pop up showing the plot.
>>
>> The toggle_interactivity() function queries matplotlib to get it's
>> current backend, and then uses that setting to choose a FigureCanvas
>> subclass to draw the plot onto.
>>
>> Unfortunately, matplotlib's support for creating working plots outside of
>> pyplot using a GUI backend is basically nil. For example, using Austin's
>> pull request with the MacOSX backend, I can't interact with the plot window
>> that pops up (mousing over it produces a beachball hang) and I need to exit
>> the python interpreter to close the window. If matplotlib is configured to
>> use the QT4 backend (e.g. most anaconda installs on linux), nothing shows
>> up except for a white window. In the TK backend, an exception gets printed
>> out. It *does* seem to work with the notebook backend though. I haven't
>> tried any of the other GUI backends.
>>
>> I didn't try manually testing Austin's pull request so the PR went
>> through a pass or two of review under the assumption that the GUI backends
>> were mostly working. I'd like to apologize to Austin for giving him
>> comments and suggestions that led to code improvements even though right
>> now I'm arguing that we should abandon the approach as implemented - I
>> could definitely have handled reviewing that PR with more empathy.
>>
>> Given that we have very little control over matplotlib's configuration
>> and which backend it will select at runtime, I don't think the API that
>> Austin has implemented will be very useful for most users. Most people will
>> either see a non-interactive plot window pop up that they can't close, no
>> plot at all, or get an error. At the matplotlib BOF at SciPy this year
>> there was some discussion about making matplotlib's backends more uniform
>> and exposing them better to the object oriented interface, but I don't
>> think it's straightforward right now to use them as we'd like to without
>> relying on pyplot somehow.
>>
>> That said, I know that Austin wants to use this for his own QT
>> application. I think the best thing to do there is to add an interface for
>> users who want to supply their own canvas objects to draw to. That way
>> anyone who wants to manage their own GUI event loop will still be able to
>> draw to a GUI canvas using yt's plotting code. I'd be very happy to spend
>> time getting this working.
>>
>> Alternatively, if we do want to keep the API Austin has worked out, I
>> think we'll need to manage our own GUI event loop, and write
>> backend-dependent support code to handle that. I think that this approach
>> will be difficult although certainly with a nice payoff - it's a very
>> commonly requested feature.
>>
>>
> I'm not sure I'm as pessimistic -- I've been experimenting with using the
> PR inside ipython with the matplotlib backend set, and it seems to work.  I
> think that it's reasonable to mandate that if we're running in an IPython
> session (not a notebook) where the thread model is set via --matplotlib= ,
> that we should allow for this functionality.
>
>

Sorry, can you clarify which backend you're using? I'm not sure there is a
"matplotlib" backend. For example, when I start IPython as you suggested, I
get the following error:

[TerminalIPythonApp] CRITICAL | Bad config encountered during
initialization:
[TerminalIPythonApp] CRITICAL | The 'matplotlib' trait of a
TerminalIPythonApp instance must be any of [u'auto', u'gtk', u'gtk3',
u'inline', u'nbagg', u'notebook', u'osx', u'qt', u'qt4', u'qt5', u'tk',
u'wx'] or None, but a value of u'' <type 'unicode'> was specified.

In your running IPython session you should be able to get the current
backend by doing:

     import matplotlib
     matplotlib.get_backend()

> Sorry that was a bit of a novel - wanted to distill my thinking on this as
>> clearly as possible.
>>
>> -Nathan
>>
>> On Thu, Jul 28, 2016 at 12:26 PM, Gilbert, Austin B <
>> agilbert39 at gatech.edu> wrote:
>>
>>> Hello All,
>>>
>>>      I recently submitted a pull request that enables all yt plots to
>>> utilize the various interactive backends matplotlib(mpl) has to offer. The
>>> primary benefit of this change is that it enables a few more features from
>>> mpl in jupyter notebooks, but it also creates the possibility for user
>>> created applications using python gui packages (pyqt, tk, cairo, etc.).
>>> However, enabling this feature outside of a notebook requires the user to
>>> configure matplotlib for the backend they are using, as well as
>>> implementing their own event loop for the application. I would like to hear
>>> from others if they feel this is to complex a task to put on the user, and
>>> also if they would utilize the feature.
>>>
>>>
>>> Austin Gilbert
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160801/7a17d687/attachment-0001.htm>