I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget canvases using qt4agg as the backend. I'm having problems with these figures popping up any time when some other part of the program calls pyplot.show().
How do you avoid this showing of previous figures? Is there some hidden buffer where the figures go? If there is, what is the way to clear this buffer, or preferably avoid putting figures in this buffer altogether? I'd be happy to handle these figures as simple individual objects.
(I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I tried deepcopying the figure and then clearing the pylab buffer with pylab.clf() , but figures don't seem to be deepcopyable.)
A typical situation is the following:
- There is a window with a widget. The widget (widgetMpl in the code below) has a slightly customized FigureCanvas in it. The drawing code is activated by clicking a button in the window. The code goes as follows.
# The plot method returns a complicated instance of Figure with several axes, constructed with Pylab.
previewFigure = self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)
- I draw the figure in the window once, or several times with different file_to_plot, by pressing the button. I may or may not close the window with the aforementioned widget.
- Elsewhere in the program there is another window with very simple drawing code using pyplot. When this code calls pyplot.show(), all the figures drawn in the first window will show up.
I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
canvases using qt4agg as the backend. I'm having problems with these
figures popping up any time when some other part of the program calls
pyplot.show().
Generally, when embedding, one simply does not use the pyplot interface at all, so this sort of problem does not arise. Is there any reason why you can't use this approach?
How do you avoid this showing of previous figures? Is there some hidden
buffer where the figures go? If there is, what is the way to clear this
buffer, or preferably avoid putting figures in this buffer altogether?
I'd be happy to handle these figures as simple individual objects.
To remove a figure created by pyplot, use pyplot.close(fig); but still, trying to use the pyplot interface for anything more complicated than direct interactive use and simple non-interactive scripts is likely to cause more problems than it solves. It's just not what pyplot is designed for.
Eric
···
On 2013/08/23 3:55 AM, Kari Aliranta wrote:
(I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I
tried deepcopying the figure and then clearing the pylab buffer with
pylab.clf() , but figures don't seem to be deepcopyable.)
A typical situation is the following:
- There is a window with a widget. The widget (widgetMpl in the code
below) has a slightly customized FigureCanvas in it. The drawing code is
activated by clicking a button in the window. The code goes as follows.
# The plot method returns a complicated instance of Figure with
several axes, constructed with Pylab.
previewFigure =
self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)
- I draw the figure in the window once, or several times with different
file_to_plot, by pressing the button. I may or may not close the window
with the aforementioned widget.
- Elsewhere in the program there is another window with very simple
drawing code using pyplot. When this code calls pyplot.show(), all the
figures drawn in the first window will show up.
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net matplotlib-users List Signup and Options
It is called the "pyplot state environment". When code uses pylab or
pyplot, the pyplot state implicitly keeps track of all the axes and figures
that are generated. The way to avoid the pyplot state environment is to
completely avoid any and all usage of pyplot. Don't even import it. Work
strictly down in the OO layer. Of course, this is difficult to do for a
variety of reasons, but it should be achievable. There are other people on
this mailing list that are much more experienced than I with the pure
OO-approach and embedding, and hopefully they can chime in with pointers
and tips.
Cheers!
Ben Root
···
On Fri, Aug 23, 2013 at 9:55 AM, Kari Aliranta < kari.p.aliranta@...4439...> wrote:
Hello, fellow Matplotlib users,
I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
canvases using qt4agg as the backend. I'm having problems with these
figures popping up any time when some other part of the program calls
pyplot.show().
How do you avoid this showing of previous figures? Is there some hidden
buffer where the figures go? If there is, what is the way to clear this
buffer, or preferably avoid putting figures in this buffer altogether?
I'd be happy to handle these figures as simple individual objects.
(I'm aware that this "hidden buffer" may be the pylab/pyplot buffer. I
tried deepcopying the figure and then clearing the pylab buffer with
pylab.clf() , but figures don't seem to be deepcopyable.)
A typical situation is the following:
- There is a window with a widget. The widget (widgetMpl in the code
below) has a slightly customized FigureCanvas in it. The drawing code is
activated by clicking a button in the window. The code goes as follows.
# The plot method returns a complicated instance of Figure with
several axes, constructed with Pylab.
previewFigure =
self.parent.experiment.file_to_plot.plot(show=False, n_channels=10)
- I draw the figure in the window once, or several times with different
file_to_plot, by pressing the button. I may or may not close the window
with the aforementioned widget.
- Elsewhere in the program there is another window with very simple
drawing code using pyplot. When this code calls pyplot.show(), all the
figures drawn in the first window will show up.
I am wondering if the problem being described here is one where someone
creates a module to do some particular thing using matplotlib, and someone
else has the script that is using pyplot and that module. I am fairly
certain that the pure OO approach should still work for the code in the
module without interference from the script's usage of pyplot, though, but
I am not 100% certain.
Cheers!
Ben Root
···
On Fri, Aug 23, 2013 at 1:57 PM, Eric Firing <efiring@...202...> wrote:
On 2013/08/23 3:55 AM, Kari Aliranta wrote:
> Hello, fellow Matplotlib users,
>
>
> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
> canvases using qt4agg as the backend. I'm having problems with these
> figures popping up any time when some other part of the program calls
> pyplot.show().
Generally, when embedding, one simply does not use the pyplot interface
at all, so this sort of problem does not arise. Is there any reason why
you can't use this approach?
>
> How do you avoid this showing of previous figures? Is there some hidden
> buffer where the figures go? If there is, what is the way to clear this
> buffer, or preferably avoid putting figures in this buffer altogether?
> I'd be happy to handle these figures as simple individual objects.
To remove a figure created by pyplot, use pyplot.close(fig); but still,
trying to use the pyplot interface for anything more complicated than
direct interactive use and simple non-interactive scripts is likely to
cause more problems than it solves. It's just not what pyplot is
designed for.
I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
canvases using qt4agg as the backend. I'm having problems with these
figures popping up any time when some other part of the program calls
pyplot.show().
Generally, when embedding, one simply does not use the pyplot interface
at all, so this sort of problem does not arise. Is there any reason why
you can't use this approach?
Thank you. I'd like to stick to pure OO, but I'm using some third party open source code that uses pylab extensively for rather large and interactive (as in "includes scrollbars, buttons and several types of events") figures. The code works nicely in itself, and has an option to return the figure object without actually showing the plot.
I was hoping to take the returned figure as an object and reset the related state environment information, effectively "smuggling" the created figure out of the state environment. If there is a simple way to do this in Matplotlib, that would be quite useful.
There is one quick-n-dirty way of doing it. And it ain't pretty.
Using the third-party code in a subprocess that creates a pickle of the
figure. Then load up the pickle and extract the figure object in your
parent process. Your instance of matplotlib will never be touched.
Told you it wasn't pretty...
Ben Root
···
On Fri, Aug 23, 2013 at 4:08 PM, Kari Aliranta < kari.p.aliranta@...4439...> wrote:
23.08.2013 20:57, Eric Firing kirjoitti:
> On 2013/08/23 3:55 AM, Kari Aliranta wrote:
>> Hello, fellow Matplotlib users,
>>
>>
>> I'm embedding some Matplotlib figures into GUI (PyQt4) windows or widget
>> canvases using qt4agg as the backend. I'm having problems with these
>> figures popping up any time when some other part of the program calls
>> pyplot.show().
>
> Generally, when embedding, one simply does not use the pyplot interface
> at all, so this sort of problem does not arise. Is there any reason why
> you can't use this approach?
Thank you. I'd like to stick to pure OO, but I'm using some
third party open source code that uses pylab extensively for
rather large and interactive (as in "includes scrollbars,
buttons and several types of events") figures. The code
works nicely in itself, and has an option to return the
figure object without actually showing the plot.
I was hoping to take the returned figure as an object and
reset the related state environment information, effectively
"smuggling" the created figure out of the state environment.
If there is a simple way to do this in Matplotlib, that
would be quite useful.
2013/8/23 Kari Aliranta <kari.p.aliranta@...4439...>:
23.08.2013 20:57, Eric Firing kirjoitti:
Thank you. I'd like to stick to pure OO, but I'm using some
third party open source code that uses pylab extensively for
rather large and interactive (as in "includes scrollbars,
buttons and several types of events") figures. The code
works nicely in itself, and has an option to return the
figure object without actually showing the plot.
I was hoping to take the returned figure as an object and
reset the related state environment information, effectively
"smuggling" the created figure out of the state environment.
If there is a simple way to do this in Matplotlib, that
would be quite useful.
The problem is when to call pyplot.close(fig). The actual visible figure on the canvas is often resized along with window it is in, in addition to being interacted with in other ways. In these cases you can't just close the figure after drawing it - if you do, the resizing results in a blank canvas and a PyDeadObjectError.
The easiest workaround to the problem is simply making the whole window modal, and closing the figure if the window is closed for any reason - or before you create a new figure. This is less than ideal, but lets the life go on in this case.
Kari
···
On 08/25/13 19:12, Goyo wrote:
Thank you. I'd like to stick to pure OO, but I'm using some
third party open source code that uses pylab extensively for
rather large and interactive (as in "includes scrollbars,
buttons and several types of events") figures. The code
works nicely in itself, and has an option to return the
figure object without actually showing the plot.
I was hoping to take the returned figure as an object and
reset the related state environment information, effectively
"smuggling" the created figure out of the state environment.
If there is a simple way to do this in Matplotlib, that
would be quite useful.