The grab_figure() command should take an optional number argument. If num is not given, the figure returned by pylab.gcf() would be grabbed, but otherwise the number given would be used for the capture. In the future, we should have a custom mpl plot window (they're easy to subclass) with a special 'insert figure' button made for inserting the figure into the notebook.
The figure from grab_figure() straddles the left margin in an odd manner. Needs fixing.
John Hunter actually suggested that if we made the notebook have a structure where each cell were a separate widget, we could have mpl interactive windows 'live' in the notebook itself. While that sounds like a neat idea for the future, I only mention it now for reference: for the moment a basic implementation which allows figure capturing is enough.
RTK: I thought about that possibility, too, but I couldn't devise a reasonable way for it to behave. If I build up a plot over several input lines, what happens to the figure (or figures!)? Does it stay where it is (giving a notebook that looks like [In, Plot, In, In, In] such that most of the commands that determine the plot come after the final plot)? Does it continually adjust its position to always follow the last input (presumably until it manually gets "fixed" and further pylab commands go to another figure)? How do multiple figures behave? How do I resize my plots? Admittedly, I have a bias against embedded "live" content like this in other contexts like the Web; I've always thought that opening a separate window was the cleaner option both from the coder's perspective and the user's.
fperez: for now, I actually like the way things are. But grab_figure() should take a few arguments like size, etc. Currently it only takes caption, and that is a no-op at this point.
