[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