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

[marius.storm-olsen at nokia.com]

W00t should have a backlog which covers the conversation, if it was done on our public channels :-)

--
Sent from my Nokia N9On 5/23/12 13:44 ext Thiago Macieira wrote:
On quarta-feira, 23 de maio de 2012 14.16.12, Alberto Mardegan wrote:
> On 05/23/2012 01:25 PM, 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.
> 
> As neither of us knows exactly how QML handles QSharedPointer (my guess
> is that it simply doesn't; QSharedPointer is a template class which can
> be used with many other types than QObject, so I don't think that
> exposing it in QML is trivial), I would simply recommend you not to use it.
> I actually mentioned QSharedPointer in a recent blog post of mine [0],
> which you might find interesting especially if your use of
> QSharedPointer is suggested by your previous experience with other toolkits.
> If you really think that QSharedPointer is absolutely necessary in your
> case (I still doubt), then just expose its QObject data to QML, since you
> also claim that you can make sure its lifetime will survive the engine.

Just a tidbit...

I've long wanted to make QSharedPointer on QObject-derivatives participate in 
the whole-tree ownership, somehow. I introduced QSharedPointer in 4.4 and I 
did some work in 4.5 to make that work.

My original solution was to have a parent only deref its children's shared 
pointer counter, deleting it only if it became zero. That means that if you 
had a QSharedPointer to an object in the middle of the hierarchy, that object 
would be orphaned instead of deleted when the parent died. The converse was 
that when the last QSharedPointer reference to a QObject went away, the object 
might survive if it still had a parent.

There were a few problems with that solution. I can remember now:

1) it didn't play very well with QWidgets after the Alien project. QWidgets 
often reference the top-level window, which is the ultimate parent widget (the 
one with no parents). Orphaning a QWidget from QWidget's destructor was a 
recipe for disaster, since the original TLW data might have been gone already.

2) it didn't play very well with QObject siblings talking to each other during 
destruction or, worse, deleting each other. This is a huge pain and source of 
complexity during QObject infanticide.

3) what happens if you had a QSharedPointer<QObject> with a parent, dropped 
the last QSharedPointer reference (it survives because of the parent) and 
later orphaned that object via setParent(0)? Should it be deleted?

The worst of it all is that I remember having a discussion during 4.6 times 
with someone on IRC and coming up with a brilliant and simple solution. 
Something like "don't orphan, but keep a refcount on the entire tree". The 
problem is that I didn't write it down, because I thought it was so simple and 
evident that I'd be able to remember or work it out again.

I haven't been able to. Fermat would be proud.

Anyway, that reminds me I have some pending QSharedPointer work to do. I'll 
get on with it.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden