-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
factor the pyplot dependence out of the figure_manager classes #2617
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
factor the pyplot dependence out of the figure_manager classes #2617
Conversation
Awesome! At a quick glance this looks like what I had in mind. I will look at it in detail tomorrow and probably produce PRs against your branch to deal with the rest of the backends. |
I still have one question. If the user doesn't want to use pyplot, how are these classes going to be used in scripting or interactive mode? |
@@ -2525,10 +2525,9 @@ class FigureManagerBase: | |||
*num* | |||
The figure number | |||
""" | |||
def __init__(self, canvas, num): | |||
def __init__(self, canvas): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could avoid this change to the base API, and thereby avoid quite a few other changes, by changing the num
argument to a kwarg with default None
. In addition to simplifying the changeset, this would avoid breaking any user-written backends that might be in use.
@efiring Yes, I know. |
@fariza, in this case I would vote for compatibility, and include a very brief comment in backend_bases.py giving the rationale. The cost of having this optional argument (and corresponding attribute) that is not always used is very low. It some ways it makes the design cleaner by reducing LOC in the end result. Even for the no-pyplot gui application, might it not be useful sometimes for the canvas to have a label or ID attribute, settable upon instantiation? |
@efiring I agree, and that was one question that I posted in another thread. How about moving the Gcf outside pylab? maybe just rename it (something else than pylab_helpers.py)? |
@fariza I think Gcf is the heart of pylab/pyplot--keeping track of a set of figures, and maintaining the notion of a current figure. Perhaps the strange thing is that another critical internal organ, the tracking of a current Axes, is inside the Figure class itself, not factored out into a pyplot-specific location. Same for the current Image (actually, mappable object). |
This is a fisrt try to remove the pyplot/pylab stuff from the figure manager.
The implementation is currently only for GTK3 for review and coments
This idea has been mentioned (mainly by @tacaswell and myself) several times in PRs #2604, #2465, #1849 and on the mailing list
Objective
The main idea is to have figure, canvas and manager that are independent from pyplot/pylab.
This brings among other things, the possibility to use the "ready to use" GUI inside other applications, without having to reconstruct the window/toolbar etc..
Proposed modifications
The new files
Contain the independent classes, that can be used anywhere without calling the pyplot/pylab stuff.
The existing files
Contain the classes that depend on pyplot/plylab. These are the classes that are currently used and can be used without any side effect.
Impact on the existing backends
There are two small modifications to the
backend_bases.py
and the respective correction for all the backends. So they should be working the same.