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

Nathan Goldbaum nathan12343 at gmail.com
Mon Aug 1 11:22:57 PDT 2016


On Mon, Aug 1, 2016 at 12:45 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Mon, Aug 1, 2016 at 12:40 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>
>> 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.
>>
>
> I can confirm that works over here too, with both the QT4 and MacOSX
> backend as well. Thanks for the suggestion! I wonder if there's a way to
> get this to work without using --matplotlib...
>


I made a commit on top of Austin's pull request that seems to make it work
much less jankily out of the box on many setups:

https://bitbucket.org/ngoldbaum/yt/commits/7ecf762119730bd6b338824b32c0664381ea4cc8

With that I withdraw my objections to merging the pull request :)


>
>
>
>>
>>>
>>>
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/055cdbe0/attachment-0001.html>


More information about the yt-dev mailing list