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

[Atlant Schmidt]

All:

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

  If only Pierre de Fermat had had that feature!

                        Atlant

-----Original Message-----
From: development-bounces+aschmidt=dekaresearch.com at qt-project.org [mailto:development-bounces+aschmidt=dekaresearch.com at qt-project.org] On Behalf Of marius.storm-olsen at nokia.com
Sent: Wednesday, May 23, 2012 09:52
To: development at qt-project.org; thiago.macieira at intel.com
Subject: Re: [Development] On QML, ownership, QObject-trees and QSharedPointer

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
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


 Click https://www.mailcontrol.com/sr/Bj8gU1boyQLTndxI!oX7UjaeDmea67kX7SqObTicsrBLI7iRALOOZRgXDSSm+ebxNAjdtRoTpmRPbv5+FCDqIw==  to report this email as spam.

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.