[PyQt] QML, pyqtSlot and ownership
Phil Thompson
phil at riverbankcomputing.com
Mon Jul 14 13:39:17 BST 2014
On 14/07/2014 12:59 pm, Nenad Ognjanovic wrote:
> Hello,
> I'd be very grateful if someone could confirm whether the solution to
> the
> following two scenarios is valid:
>
> I'd like to be able to call a pyqtSlot from QML, have the slot
> instantiate
> and return a QObject, and have the QML take over the ownership of the
> object, without having to keep an explicit reference to the object on
> the
> python side. Without explicitly using sip.transferto (as suggested in
> this
> stackoverflow answer http://stackoverflow.com/a/24696295/858766 - the
> question was posted by me, please go through it if you have time), the
> object is garbage collected before it even reaches the QML side.
> Is using sip.transferto the correct approach here?
>
> Additionally, there's a similar problem when the situation is reversed.
> If
> I expose a class Dummy via qmlRegisterType and then instantiate it in
> QML
> using Dummy {} (e.g. as a ListView delegate), a segfault will occur as
> soon
> as the delegate gets out of ListView visible area and gets destroyed.
> In
> this case I can add sip.transferto in the constructor but it doesn't
> seem
> right, and it also causes the process to not quit after the event loop
> exits. Should I transfer the ownership back?
> Is sip.transferto even something a PyQt user should be using and be
> aware
> of?
>
> In both cases I don't see the destructors being triggered (by the fact
> that
> there's no print output from the overridden __del__ and connected
> destroyed
> signal handler), which contributes to my concern about the approach.
How would it work in C++?
In other words, is the PyQt behaviour correct and in C++ you rely on
memory leaks (ie. the object existing without there being a reference to
it)?
Or is there a PyQt ownership bug?
Phil
More information about the PyQt
mailing list