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

[Nathan Goldbaum]

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160728/e2116671/attachment.html>