[Development] On QML, ownership, QObject-trees and QSharedPointer

Stephen Kelly stephen.kelly at kdab.com
Wed May 30 13:22:56 CEST 2012


On 29.05.2012 10:55, Rene Jensen wrote:

>>> Question: How can we expose objects governed by QSharedPointer to 
>>> QML
>>> safely? I *can* guarantee the lifecycle beyond the life of my
>>> QDeclarativeEngine.
>> If you can guarantee that, then use mySharedPtr.data() as others 
>> have
>> said.
>
> Just a quick thought, would that suggesion be leading into trouble? 
> In
> only see one way to do that right:
>
> Step 1: mySharedPtr.data() ==> MyShared* P;
> Step 2: make sure the QML engine doesn't assume ownership:
> QDeclarativeEngine::setObjectOwnership
> Step 3: hand over P to QML: setProperty or setContextProperty

Yep, those steps seem to be the current requirement. If my patches get 
in (not guaranteed), it will be reduced to just:

Step 1: setContextProperty("myname", mySharedPtr);

or

Step 1: setContextProperty("myname", mySharedPtr.toWeakRef());

depending on your needs.

>
> When I said the database layer should preferably remain QML agnostic,
> I merely wanted to keep "patchup code" like "setObjectOwnership" out
> of a clean set of data classes for purist reasons. (Really it is an
> exaggeration imho.. I have no problem using stuff from QtDeclarative
> in code. Will need it for QList properties anyway. It's just a design
> reflex).

Yes, I agree.

> Leaving out step 2 is bad, right?

Yes, and worse it might not obvious to consumers of the API that it's 
needed.

Thanks,

-- 
Stephen Kelly | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions



More information about the Development mailing list