OO inteface question.

Hi all, There has been some recent discussion about perhaps

    > improving the OO interface. So Here's a question:

    > How do I save an AGG figure with the OO interface?

Hi Chris,

Here is a canonical script to create an Agg canvas/figure and save it
using the pure OO interface. The distinction between the figure and
the canvas was made to fully separate the front end from the backend.
The Figure is the abstract object that stores all the information
about the figure, the canvas is where the ink goes. I agree there
could be some changes to the interface to make this easier, but here
the pure OO way:

    from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
    from matplotlib.figure import Figure

    fig = Figure()
    canvas = FigureCanvas(fig)
    ax = fig.add_subplot(111)
    ax.plot([1,2,3])
    ax.set_title('hi mom')
    ax.grid(True)
    ax.set_xlabel('time')
    ax.set_ylabel('volts')
    canvas.print_figure('test')

    > For example:
    >>>> fig = pylab.figure() ax = fig.add_subplot(1,1,1)
    >>>> ax.plot(range(10), pylab.sin(range(10)))

    > Now how do I save it as a PNG? I can do:

    >>>> pylab.savefig("test.png")

    > But then that is the interface I'm trying to get away from.

Hmm, I don't see the logic of being willing to use some pylab commands
(pylab.figure) but not others (pylab.savefig). But, if you really
hate savefig, you can call print_figure by getting your hands on the
current canvas

    import matplotlib
    matplotlib.use('Agg')
    import pylab

    fig = pylab.figure()
    ax = fig.add_subplot(111)
    ax.plot([1,2,3])

    manager = pylab.get_current_fig_manager()
    manager.canvas.print_figure('test')

Kind of awkward. This is basically what savefig does.

    > Another option would be:

    >>>> fig.savefig

    > But that's not there either.

As we discussed earlier, it might be useful for the figure to store a
ref to it's canvas, then we could define fig.savefig which forwards
the call to canvas.print_figure. Would make for a cleaner interface
for folks who love '.'

JDH

John Hunter wrote:

    > How do I save an AGG figure with the OO interface?

The distinction between the figure and
the canvas was made to fully separate the front end from the backend.

Which is a good idea.

> here the pure OO way:

    from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
    from matplotlib.figure import Figure

    fig = Figure()
    canvas = FigureCanvas(fig)

So this is really the only extra call. not bad.

    ax = fig.add_subplot(111)
    ax.plot([1,2,3])
    ax.set_title('hi mom')
    ax.grid(True)
    ax.set_xlabel('time')
    ax.set_ylabel('volts')
    canvas.print_figure('test')

Hmm, I don't see the logic of being willing to use some pylab commands
(pylab.figure) but not others (pylab.savefig).

Well, the figure constructor has to be in some namespace.

pylab.savefig, however, bothers me for two reasons:

1) It seems to me that it belongs as a figure (or canvas, I suppose) method.

2) Most critically, it uses the "current figure". I can see where this makes sense with Matlab style interactive use, but in a program, I may be building more than one figure at a time, and it makes more sense to me to do something like:

fig1.save("plot1")
fig2.save("plot2")

than:
set_current_figure(1)
pylab.savefig("plot1")
set_current_figure(2)
pylab.savefig("plot2")

> But, if you really

hate savefig, you can call print_figure by getting your hands on the
current canvas

    manager = pylab.get_current_fig_manager()

Ah, the "current" concept again!

As we discussed earlier, it might be useful for the figure to store a
ref to it's canvas, then we could define fig.savefig which forwards
the call to canvas.print_figure. Would make for a cleaner interface
for folks who love '.'

Yes, I confess, I love ".". That does sound like a good idea to me.

Sorry to come off as being critical. I am very impressed with your work on matplotlib. There are been many promising starts to a python plotting package, and NONE of them have come even close to what you've done with matplotlib. That's why I'm using it. I also was a big fan and user of Matlab for years, I never would have gotten my dissertation done without it. However, I like Python as a language far more than Matlab, and with SciPy and matplotlib, we're getting close to having Matlab's wealth of functionality in Python. My ideal is that I have a plotting package that really feels Pythonesque. Matplotlib is actually pretty close. I think adding a few things, and making more docs and examples, and we'll have just what I've been wanting.

I hope as I get more familiar with matplotlib, I'll start to contribute code, rather than just questions and criticism.

John, do you want patches that add-to/improve the OO interface?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                         
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...