[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] =?utf-8?q?QWidget_=27destroyed=27_signal=3A_possible_regre?=
From:       Phil Thompson <phil () riverbankcomputing ! com>
Date:       2012-03-11 11:05:07
Message-ID: b8ead1a28bcc7a768f7d2ea813675d8d () localhost
[Download RAW message or body]

On Sun, 11 Mar 2012 11:48:44 +0100, Erik Janssens
<Erik.Janssens@conceptive.be> wrote:
> Hello Pierre, Phil,
> 
> I'm not so sure the current behavior is inconsistent.  One
> of the reasons of using signal/slot over normal callbacks is
> that they are disconnected when one of the objects gets
> deleted.
> 
> So if you connect the destroyed signal to a non-QObject-method, the
> slot is called.  If you connect it to a QObject-method that has
> been deleted, the slot is not called.  

Yes - but the point is that it hasn't yet been deleted.

> The destroyed signal is emitted in the destructor of QObject.  So in
> case of a QWidget, this after the QWidget destructor has done its work.
> After this has been done, any call to a QWidget method might crash the
> application.
>
> I would prefer the behavior to be consistent with C++ Qt (although
> I don't know what that exactly is)

I think the (now changed) behaviour is consistent.

> The documentation of Qt states that the destroyed signal should be
> used to monitor a QObject, I don't think its intended to serve
> as a kind of destructor.

Agreed - which is why I said I considered this particular usage an
application bug.

> It's worth thinking this through before changing it...

It's been changed - but it can always be changed back if current snapshots
prove to be a problem.

Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]