matplotlib-devel Mailing List for matplotlib

On Sun, Feb 26, 2012 at 9:26 AM, Pierre Raybaut <pie...@gm...>wrote:
> I found out that a similar issue was reported for Spyder the same day
> as this one...
>
> So I just posted something about this bug on PyQt mailing list:
> http://www.riverbankcomputing.com/pipermail/pyqt/2012-February/031166.html
>
>
I added your fix in pull request
https://github.com/matplotlib/matplotlib/pull/716 so it should come out in
the bug fix release we are preparing.
Also, something you might be interested in for your qt apps: I exposed the
default mpl key handling to embedded applications
https://github.com/matplotlib/matplotlib/pull/717
Thanks a bunch for the suggested fix -- this was a vexing issue and
particularly bad for the animation examples which caused all of my demos to
explode is a sea of C++ warnings when I closed the window.
JDH

I found out that a similar issue was reported for Spyder the same day
as this one...
So I just posted something about this bug on PyQt mailing list:
http://www.riverbankcomputing.com/pipermail/pyqt/2012-February/031166.html
-Pierre
Le 26 février 2012 12:23, Pierre Raybaut <pie...@gm...> a écrit :
> Le 25/02/2012 22:59, John Hunter a écrit :
>
>
>
> On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root <ben...@ou...> wrote:
>>>
>>>
>>> >   I would be interested in accelerating the schedule. Since this is
>>> > a
>>> >   bug-fix release and not a major release, we can presume the tree is
>>> >   pretty stable. How about we aim for an release candidate rc1 the
>>> >   week after next? Are there any issues or pull requests that should
>>> >   hold the release? If so, let's tag them with release-critical.
>>> >
>>> >   After we get the bugfix out I'd like to gear up for a major python3
>>> >   release.
>>> >
>>> >
>>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>>> > into them and there is no obvious reason to me why they aren't working.
>>>
>>> Are you referring to 771, 707, and 525? 771 would appear to be the
>>> most urgent.
>>
>>
>> 711 and 707. Didn't even notice 525, but it is probably related to 707.
>> If true, then 707 and 525 are likely focus issues (maybe window-manager
>> dependent?). 711 definitely seem to be release blocking.
>>
>
>
> Hi Pierre, we are still having trouble with the close event in mpl figure
> windows not being emitted. I see you posted on this subject in 2009 and did
> some monkey patching to work around the problem for spyder
>
> http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html
>
> This was a while ago so I don't know if your suggestions are still
> appropriate for recent pyqt and mpl. Would you have a minute to take a look
> at this mpl issue
>
> https://github.com/matplotlib/matplotlib/issues/711
>
> and advise us on a fix?
>
> Thanks,
> JDH
>
>
>
>
> Hi John,
>
> Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
>     QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
>                self.close_event)
> by this:
>     QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
>                lambda: self.close_event())
> will solve this issue.
>
> The reason is that PyQt fails (silently) to call a method of this object
> just before detroying it. Using a lambda function will work, exactly the
> same as using a function (which is not bound to the object to be destroyed).
>
> Side note: I'm not sure that it's the intended behavior for PyQt...
>
> HTH,
> Pierre

Hi,
I will be on vacation with limited email from February 18-25, 2012.
Bonjour,
Je serai en conge du 18 au 25 fevrier, 2012.
Thanks,
David

 Le 25/02/2012 22:59, John Hunter a écrit :
On Sat, Feb 25, 2012 at 1:54 PM, Benjamin Root <ben...@ou...> wrote:
>
>> > I would be interested in accelerating the schedule. Since this is a
>> > bug-fix release and not a major release, we can presume the tree is
>> > pretty stable. How about we aim for an release candidate rc1 the
>> > week after next? Are there any issues or pull requests that should
>> > hold the release? If so, let's tag them with release-critical.
>> >
>> > After we get the bugfix out I'd like to gear up for a major python3
>> > release.
>> >
>> >
>> > The QT4 event handling bugs needs a qt expert on them. I tried looking
>> > into them and there is no obvious reason to me why they aren't working.
>>
>> Are you referring to 771, 707, and 525? 771 would appear to be the
>> most urgent.
>
>
> 711 and 707. Didn't even notice 525, but it is probably related to
> 707. If true, then 707 and 525 are likely focus issues (maybe
> window-manager dependent?). 711 definitely seem to be release blocking.
>
>
 Hi Pierre, we are still having trouble with the close event in mpl figure
windows not being emitted. I see you posted on this subject in 2009 and
did some monkey patching to work around the problem for spyder
http://old.nabble.com/Qt4-backend%3A-critical-bug-with-PyQt4-v4.6%2B-td26205716.html
This was a while ago so I don't know if your suggestions are still
appropriate for recent pyqt and mpl. Would you have a minute to take a
look at this mpl issue
 https://github.com/matplotlib/matplotlib/issues/711
 and advise us on a fix?
 Thanks,
JDH
Hi John,
Replacing this (backend_qt4.py, class "FigureCanvasQT", line 141):
 QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
 self.close_event)
by this:
 QtCore.QObject.connect(self, QtCore.SIGNAL('destroyed()'),
 lambda: self.close_event())
will solve this issue.
The reason is that PyQt fails (silently) to call a method of this object
just before detroying it. Using a lambda function will work, exactly the
same as using a function (which is not bound to the object to be destroyed).
Side note: I'm not sure that it's the intended behavior for PyQt...
HTH,
Pierre