Skip to content

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

Closed

Conversation

fariza
Copy link
Member

@fariza fariza commented Nov 27, 2013

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

  • backend_gtk3_gui.py
  • backend_gtk3agg_gui.py
  • backend_gtk3cairo_gui.py

Contain the independent classes, that can be used anywhere without calling the pyplot/pylab stuff.

The existing files

  • backend_gtk3.py
  • backend_gtk3agg.py
  • backend_gtk3cairo.py

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.

@tacaswell
Copy link
Member

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.

@fariza
Copy link
Member Author

fariza commented Nov 28, 2013

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?
Or is it mandatory to use pyplot for scripting or interactive mode?

@@ -2525,10 +2525,9 @@ class FigureManagerBase:
*num*
The figure number
"""
def __init__(self, canvas, num):
def __init__(self, canvas):
Copy link
Member

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.

@fariza
Copy link
Member Author

fariza commented Nov 28, 2013

@efiring Yes, I know.
But because the idea was to separate the two, leaving the num argument there made no sense.
For backward compatibility it makes sense.
So I don't know what has priority, design goal or compatibility.

@efiring
Copy link
Member

efiring commented Nov 28, 2013

@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?

@fariza
Copy link
Member Author

fariza commented Nov 28, 2013

@efiring I agree, and that was one question that I posted in another thread.
Personally I feel the num to be useful, the only "problem" is that it belongs to pylab.

How about moving the Gcf outside pylab? maybe just rename it (something else than pylab_helpers.py)?
Why is not automatically assigned at figure instantiation?

@efiring
Copy link
Member

efiring commented Nov 28, 2013

@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).
The overall strategy for any refactoring deserves more thought than I can give it at the moment, unfortunately.

@tacaswell tacaswell mentioned this pull request Nov 29, 2013
9 tasks
@fariza fariza closed this Nov 29, 2013
@fariza fariza deleted the removing_pyplot_pylab_from_backends branch February 11, 2015 18:09
@leycec leycec mentioned this pull request Dec 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants