clearing a figure

However, it is the case that there is a lot of stuff

    > in pylab that makes it easier to use MPL in
    > interactive mode. I kind of think that's a shame. I
    > don't think that there is any reason that an OO
    > interface is less suited to interactive mode.

It's currently implemented in pylab but could be moved up to the OO
layer by doing something like

class Axes:
   def plot(self, *args, **kwargs):
       ...plot something
       if rcParams['interactive']:
            self.figure.canvas.draw()

or by providing some autowrapper facility to automate this. Probably
could be done elegantly with decorators, but we can't use decorators
yet...

Or OO users can just call fig.canvas.draw() themselves when they want
to draw....

JDH

John Hunter wrote:

It's currently implemented in pylab but could be moved up to the OO
layer by doing something like

class Axes:
   def plot(self, *args, **kwargs):
       ...plot something
       if rcParams['interactive']:
            self.figure.canvas.draw()

or by providing some autowrapper facility to automate this.

That could work -- and/or subclass the key classes, and wrap their plot, etc. methods. hmmm..

Or OO users can just call fig.canvas.draw() themselves when they want
to draw....

Well, yes, but the point I'm making is that it should be just as easy to use interactively -- that's a bit too much code to want to type at the command line.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...

John Hunter wrote:

    > However, it is the case that there is a lot of stuff
    > in pylab that makes it easier to use MPL in
    > interactive mode. I kind of think that's a shame. I
    > don't think that there is any reason that an OO
    > interface is less suited to interactive mode.

It's currently implemented in pylab but could be moved up to the OO
layer by doing something like

class Axes:
   def plot(self, *args, **kwargs):
       ...plot something
       if rcParams['interactive']:
            self.figure.canvas.draw()

I think this may be a slippery slope. The problem is that for it to work well, there has to be a clear distinction between methods that are endpoints, requiring a redraw, and methods that will be used by other methods. For example, errorbar makes multiple calls to plot, vline, etc. Even in interactive mode, we don't want redraws after each of those calls, only after the errorbar call itself. This could be handled by including an additional kwarg ("redraw=False"), or by requiring that methods like errorbar use only lower-level primitives, but either way, complexity increases.

Eric

···

or by providing some autowrapper facility to automate this. Probably
could be done elegantly with decorators, but we can't use decorators
yet...

Or OO users can just call fig.canvas.draw() themselves when they want
to draw....

JDH

Eric Firing wrote:

I think this may be a slippery slope. The problem is that for it to work well, there has to be a clear distinction between methods that are endpoints, requiring a redraw, and methods that will be used by other methods. For example, errorbar makes multiple calls to plot, vline, etc.

I agree -- I don't mind a call to Draw() or something now and then. maybe I can put them in my hypothetical OOlab (see prev. msg.) some day, so that there are a few calls that do the draw, but not every call to plot().

> by including an additional kwarg ("redraw=False"),

That's the question -- in my wxPython FloatCanvas, I decided that NOTHING redraws, and you have to make a call to Draw(0 to get a re-draw. In fact, that won't even work if the Canvas thinks nothing has changed, so you sometimes need to call Draw(force=True). In that case, I was optimizing for fast drawing of lots of stuff, and for embedding in a program -- not interactive use.

I do like the default redraw of False that can be overridden -- but how many places will that have to be added to the code?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@...259...