Re: [Matplotlib-users] OO inteface question.

[Chris B. <Chr...@no...>]

John Hunter wrote:
>     Chris> 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

Chr...@no...