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

Mon Aug 1 10:40:10 PDT 2016

Hi Nathan,

On Mon, Aug 1, 2016 at 10:37 AM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> 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.
>

I was using --matplotlib=qt

I can't use the OSX one, but with that I was able to generate windows, and
continue using the console.

>
>
> 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
>>
>>
>
> _______________________________________________
> 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/c3103113/attachment.htm>