but our goal is to un pin freetype
I haven't tested them, but the building works: https://github.com/QuLogic/matplotlib/actions/runs/335123526
I feel like I remember having a rundown of all the containers that Matplotlib expects, but I can't remember any other details.
Or do you think the audience will need more details like examples of the supported containers ?
Is this a bug? (log axis scaling) https://twitter.com/DelocalizedD/status/1321901339119656961?s=19
I think another approach, which we have discussed, and seems trivial, is to move
plt.figure, and plt.subplots into matplotlib/__init__.py and then ask people to not do import matplotlib.pyplot as plt. That will instantly raise if they accidentally cut-and-paste some pyplot code in.
that is something we definitly can not pull up into the top level import
right now you can do
fig = mpl.figure.Figure(); ax = fig.subplots() and get a figure fully managed by you (we hold no references to it)
but it will have the Agg canvas (not one of the GUI ones)
@story645 It's clear as someone who understands programming languages! Seeing as the survey results in most users comfortable with Python, I don't see it as an issue with the phrasing. As for examples, it'll likely be basic Python data containers and two NumPy arrays as demonstrative examples. Thanks!
We have
mpl.use so why can't we manage the backend?
when you do
plt.figure we are creating a Figure, a canvas (of the correct GUI class), a manager, a window, a toolbar, and registering the manger with our global registry of open figures
it defaults to figurecanvasbase
however, if you decide to do a savefig with it, we know that if you want to save a png you can use agg (or if you want to save a pdf you can use the pdf backend, etc.) and we temporarily switch the backend just for the duration of the save
(I would certainly not want to make things default to agg :))
I'm not at all familiar with the ins and outs, but it looks like it is all managed by
_pylab_helper.Gcf class? Are there other hooks to pyplot in there? I'm certainly not saying get rid of pyplot, so if someone did import pyplot and do plt.gcf() that should be fine and could raise the last created figure. But if they didn't import pyplot they would protect themselves from plt.pcolormesh
@anntzer sorry, I knew that
If we are going to create GUI windows for the user then that implies we must create (or discover the existing singleton) of what ever object the toolkit uses to give you access to the main loop. At that point we are (more-or-less) a full-on GUI application (just driven 100% from the terminal!). If we are going to create new windows under the GUI framework we should keep track of them (as there are apparently ways to orphan them, we have at least 1 qt bug for this). That global state of "the currently open windows" is what can not be done at the top level of mpl. If we wanted a "figure factory and management only" module that only gives you
figure, subplots, and subplots_mosaic that seems reasonable.
we could certainly imagine a model where the call to
show is spelt plt.show([fig1, fig2, ...]) (for example) (I think I have a PR enabling that somewhere...)
and I guess even if we do keep track of them so that
plt.show() magically pops up all figures, that doesn't mean that we have to have a notion of current figure
Because we should not be accumulating global state at the top level
if it is at the top level then there is no way for users to fully opt-out of having to deal with that code (where as if it is down a layer they only get it if they import that module)
what frameworks can mess up is the C++ side getting gc'ed before the python side (hence the
if self checks in backend_wx and sip.isdeleted(...) in backend_qt)
I don't know about the other direction but I don't think anything bad can happen