[PyQt] QML, pyqtSlot and ownership

[Phil Thompson]

On 14/07/2014 4:49 pm, Nenad Ognjanovic wrote:
> Phil Thompson <phil <at> riverbankcomputing.com> writes:
> 
>> 
>> 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?
>> 
> 
> As far as the first scenario goes (returning QObjects from slots), the
> object does get garbage collected by the QML engine so it's not exactly 
> a
> memory leak. I also cannot claim that it's a PyQt bug, but from Qt
> framework standpoint the documentation does say that the C++ object
> ownership should be taken over by QML if the parent wasn't assigned to
> the instantiated object:
> 
>> When data is transferred from C++ to QML, the ownership of the data
>> always remains with C++. The exception to this rule is when a QObject
>> is returned from an explicit C++ method call: in this case, the QML
>> engine assumes ownership of the object, unless the ownership of the
>> object has explicitly been set to remain with C++ by invoking
>> QQmlEngine::setObjectOwnership() with QQmlEngine::CppOwnership
>> specified.
>> 
>> Additionally, the QML engine respects the normal QObject parent
>> ownership semantics of Qt C++ objects, and will not ever take 
>> ownership
>> of a QObject instance which already has a parent.
> 
> link:
> http://qt-project.org/doc/qt-5/qtqml-cppintegration-data.html#data-ownership
> 
> The problem when python comes into play is that object never reaches 
> QML
> so it doesn't get a chance to get taken over. I'd expect PyQt to
> intervene here and keep the object alive, so that it's congruent with 
> the
> default Qt behavior.

Should be fixed in tonight's snapshot - so long as you call 
QQmlEngine.setObjectOwnership() in the slot.

Thanks,
Phil