[Development] Improving QtQuick internals (was Re: QML engine changes)

[Alan Alpert]

On Fri, Jun 28, 2013 at 1:48 AM, Nils Jeisecke <njeisecke at saltation.de> wrote:
> Hi Alan,
>
> On Fri, Jun 28, 2013 at 9:25 AM, Alan Alpert <416365416c at gmail.com> wrote:
>> There is. The QQuickItem tree and the QObject tree are technically
>> separate. Usually when you assign QQuickItem parentage it also assigns
>> QObject parentage, but that's because of how the QML language
>> implicitly defines a QObject tree in a similar way to how QQuickItem
>> does it. Using "parent:" messes that up.
> thank you very much for your comments. But wouldn't this classify any
> reparenting of objects that are declared in the tree as "bad Qml"? Or
> does it make any difference whether parent is assigned during
> initialization (like in the example) or afterwards (e.g. in a state
> change).
> If it does that would imply an undefined behavior, which should be
> forbidden or at least generate a warning.

During initialization or afterwards does make a big difference. The
various initialization statements are the parts which a declarative
language can theoretically implement in an undefined order. Anything
tied to an actual event (a state change, or in a signal handler like
Component.onCompleted) has a defined place in the program flow and
thus is not bad (although doing something imperatively when you could
do it declaratively is not great, that's a bit of a different issue).

> Unfortunately using Qml also means experimenting a lot. And if
> something works as expected, you're easily tempted to consider this as
> good practice ;-)

Yeah, can't fault you for sticking with what works :) . This is why we
tend to be strict about what works in order to encourage good
application patterns, like how anchors can't be set to un-related
items. I think we might want to disable setting the "parent" property
from QML in a future version of QtQuick, to prevent this kind of
mistake.

--
Alan Alpert