Repository navigation
Tell IPython the correct GUI event loop to use for all backends. - #12637
Conversation
|
This is probably the right way to do this, definitely need to negotiate with the IPython folks to make this a bit more of a documented interface. |
|
I'm happy to get any patch in IPython that can help you. I suppose we should probably find a nice way to register new backends with IPython (entrypoints ?). I'm also limited in bandwidth since I'm not 100% jupyter-funded, so I'm happy to work on giving access to the repository/PYPI/.... etc if I become a blocking factor. |
I don't think that really helps as Matplotlib's current policy is that any module can be a backend, as long as it defines the correct functions/classes/attributes. I am reasonably happy with the solution in this PR (i.e., let the backend register itself to IPython's table when a canvas is about to be created (which is more or less the latest the registration can be done)). Alternatively, IPython could itself have the code that tries to read |
IPython currently uses a hard-coded table (IPython.core.pylabtools.backend2gui) to know which event loop to use for which backend. This approach fails for both the new builtin cairo-based backends (which do not appear in the table), and for third-party backends (e.g. mplcairo). mplcairo has used some custom code to patch that table for a while; reuse it to more generally use the new "required_interactive_framework" attribute. Note that this PR suggests that there should be a better way to go back from the canvas class to the backend module (rather than looking for `sys.modules[cls.__module__].required_interactive_framework`, which is a bit hacky and could in theory fail if the canvas class is actually defined in another submodule).
|
rebased |
|
I'm in favor of merging this as long as @Carreau does not tell is it is too hacky. |
|
@Carreau did you have a minute to look at this? |
![MeeseeksDev[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
… to use for all backends.
|
@Carreau did not tell us it was too hacky. If it is, I imagine we can back it out.... |
…637-on-v3.1.x Backport PR #12637 on branch v3.1.x (Tell IPython the correct GUI event loop to use for all backends.)
IPython currently uses a hard-coded table
(IPython.core.pylabtools.backend2gui) to know which event loop to use
for which backend. This approach fails for both the new builtin
cairo-based backends (which do not appear in the table), and for
third-party backends (e.g. mplcairo).
mplcairo has used some custom code to patch that table for a while;
reuse it to more generally use the new "required_interactive_framework"
attribute.
Note that this PR suggests that there should be a better way to go back
from the canvas class to the backend module (rather than looking for
sys.modules[cls.__module__].required_interactive_framework, which is abit hacky and could in theory fail if the canvas class is actually
defined in another submodule).
(Edits:
Actually the "hack" above "sort-of" fails for Qt4 in the sense that
backend_qt4agg.FigureCanvasis actually the same class asbackend_qt5agg.FigureCanvas, so trying to reach the required_interactive_framework that way will point to "qt5". But fortunately ipython maps both "qt4" and "qt5" to "qt", so we're fine...Perhaps we can just mandate that the
__module__attribute of FigureCanvas subclasses must point to their actual backend module name. It's not as if requiring that the backend module name be stored in another attribute really helps.)Fixes #10763.
attn @Carreau
PR Summary
PR Checklist