-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[MNT]: Deprecate per-backend customization of draw_if_interactive #23105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In general, 👍 on simplifying the backend interface.
We should coordinate with them whether they think it's feasible (Maybe even open a PR for them?). IMHO we have an interest in people picking up the new API and thus should not make the barrier too high. Could other applications like spyder, vscode, pycharm, be affected? I have a vague memory that they mess with the backend internals as well. |
My plan is indeed to open the PRs for them (as this also ensures that the API I propose actually makes sense). Pycharm could also use the same mechanism, indeed (for their interagg backend, which currently customizes draw_if_interactive to mean more or less I'll mark this as release critical so that if I don't get around to implement this change in 3.6, I'll switch off (for that release only) the generation of new_figure_manager from new_manager, i.e. prevent usage of the new backend definition API, which should make it easier to enforce the deprecation of draw_if_interactive (as explained above). |
I think Spyder relies on the provided backends, sort of through ipython. But there is a bit of code involved to make it work with event loops and so on. For example, one can set the backend through a Spyder preference menu. |
This is now waiting on ipython/matplotlib-inline#15 and matplotlib/ipympl#468. |
The above-mentioned PRs have been merged, now this is implemented at #23291. |
Summary
Backends can provide a draw_if_interactive function, which, if present, gets used as the implementation of plt.draw_if_interactive. If not, the default behavior of that function is to do nothing in noninteractive; if in interactive mode, it calls draw_idle() on the active canvas. The only places where Matplotlib calls draw_if_interactive itself is at the end of figure() and of figure unpickling, to trigger a first draw. Prior to the introduction of Artist.stale, it was also called at the end of each pyplot plotting method, but this is now handled by the stale callback (which calls draw_idle(), and is not overridden by a backend-provided draw_if_interactive; however, backends could still register their own stale callback).
As part of my "move everything backend-related to FigureCanvas" work, I would like to deprecate per-backend customization of draw_if_interactive (i.e. plt.draw_if_interactive would remain present, but always just be "if in interactive mode, call draw_idle() on the active canvas"). No builtin backend actually relies on this mechanism, but there's at least ipympl and matplotlib-inline who do customize it in non-trivial ways; however, they could move their custom logic to draw_idle() instead (keeping track of whether this is the first call to draw_idle). I would like to know if there's opposition to such a change.
It would be slightly annoying if we said e.g. "if your backend provides a draw_if_interactive, then emit a DeprecationWarning", because this would make it impossible to write third-party backends that work both with the old and the new backend APIs (as defined in #23101). However, we can take advantage of the introduction of the new backend API to say "if you want to move to the new API, you must do it all at once; specifically, if you don't provide a new_figure_manager function, then we won't look for a draw_if_interactive function either". To do so, this behavior needs to be introduced in 3.6 (at the same time as the new backend API); hence, I open this issue mostly to add this to the 3.6 milestone.
Proposed fix
No response
The text was updated successfully, but these errors were encountered: